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1 Introduction 

Integrating the Healthcare Enterprise (IHE) is an initiative designed to stimulate the integration 
of the information systems which support modern healthcare institutions. Its fundamental 
objective is to ensure that in the care of patients, all required information for medical decisions is 
both correct and available to healthcare professionals. The initiative is sponsored by the 
Healthcare Information and Management Systems Society (HIMSS) and the Radiological 
Society of North America (RSNA). 

The IHE initiative provides a visible forum for encouraging the advancement and convergence of 
integration efforts through the definition of a technical framework and a multi-year series of 
public demonstrations of products implemented by industry in accordance with that framework. 
This document defines the IHE Technical Framework for Year 2 of the initiative, culminating in 
demonstrations at the annual meetings of the RSNA in November-December 2000 and HIMSS 
in February 2001. 

The approach employed in the IHE initiative is not to define new integration standards but rather 
to support the use of existing standards, e.g. DICOM, HL7, et al., in their respective domains in 
an integrated manner, defining configuration choices when necessary. When clarifications or 
extensions to existing standards are necessary, IHE refers recommendations to the relevant 
standards bodies. 

1.1 Overview 

The IHE Technical Framework identifies a subset of the functional components of the healthcare 
enterprise and specifies their interactions in terms of a set of coordinated transactions. The 
remainder of this document describes those transactions in progressively greater depth, starting 
with a transaction model at the enterprise level and proceeding through to the detailed definitions 
of each transaction. 

Section 2 presents the conventions used in the IHE Technical Framework, including the 
structures of the interaction diagrams that specify sequences of actions in transactions and the 
formats of tables that define the contents of messages. 

Section 3 defines the system transaction model adopted by the IHE Technical Framework. The 
model consists of a set of actors which interact through transactions. Actors are information 
systems or components of information systems which produce, manage, or act on categories of 
information required by operational activities in the enterprise. Transactions are interactions 
between actors which transfer the required information through standards-based messages. 
Following the transaction diagram, the actors and transactions are briefly described. 

Section 4 documents the IHE data model in an Entity Relationship (ER) diagram. 

Section 5 describes a set of typical process flows by documenting the sequence of transactions 
which take place among the involved actors. The transactions in each example are introduced in 
an interaction diagram which specifies the information flow and the temporal sequence. 
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Section 6 defines each transaction in detail, specifying the roles for each actor, the standards 
employed, the information exchanged, and the conditions under which the transaction is required 
or optional. 

The appendices following the main body of the document provide clarification of technical 
details of the IHE data model and transactions. 

The final section of the document is a glossary of terms and acronyms used in the IHE Technical 
Framework, including those from relevant standards (HL7 and DICOM). 

1.2 Audience 

The intended audience of this document is: 

• Technical staff of vendors planning to participate in the IHE initiative 

• IT departments of healthcare institutions 

• Experts involved in standards development 

• Anyone interested in the technical aspects of integrating healthcare information systems 

1 .3 Relationship to Standards 

The IHE Technical Framework identifies functional components of a distributed healthcare 
environment solely from the point of view of their interactions in the healthcare enterprise. At its 
current level of development, it defines a coordinated set of transactions based on the HL7 and 
DICOM standards. As the scope of the IHE initiative expands, transactions based on other 
standards will be included as required. 

In some cases, IHE recommends selection of specific options supported by these standards; 
however, IHE does not introduce technical choices that contradict conformance to these 
standards. If errors in or extensions to existing standards are identified, IHE’s policy is to submit 
those to the appropriate standards bodies for resolution within their conformance and standards 
evolution strategy. IHE is therefore an implementation framework, not a standard. Referencing 
IHE as a standard and claiming conformance to IHE are both inappropriate. Conformance claims 
shall be made in direct reference to specific standards. DICOM or HL7 conformance statements 
may, however, state that the products they describe are “implemented in accordance with the 
IHE Technical Framework”. 

IHE encourages implementors to ensure that products implemented in accordance with the IHE 
Technical Framework also meet the full requirements of the standards underlying IHE, allowing 
the products to interact, although possibly at a lower level of integration, with products which 
have been implemented in compliance with the standards but which may not meet the IHE 
requirements. 

1.4 Relationship to Real-world Architectures 

The actors and transactions described in the IHE Technical Framework are abstractions of the 
real-world healthcare information system environment. While some of the transactions are 
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traditionally performed by specific product categories (e.g., HIS, RIS, PACS, or modalities), the 
IHE Technical Framework intentionally does not associate functions or actors with such product 
categories. For each actor, the IHE Technical Framework defines only those functions associated 
with integrating information systems. The IHE definition of an actor should therefore not be 
taken as the complete definition of any product which might implement it, nor should the 
framework itself be taken as the complete definition of a healthcare information system 
architecture. The reason for defining actors and transactions is to provide a basis for defining the 
interactions among functional components of the healthcare information system environment. In 
situations where a single physical product implements multiple functions, only the interfaces 
between the product and external functions in the environment are considered to be significant 
by the IHE initiative. Therefore, the IHE initiative takes no position on the relative merits of an 
integrated environment based on a single, all-encompassing information system and one based 
on multiple systems which together achieve the same end. To illustrate most dramatically the 
possibilities of the IHE Technical Framework, however, the IHE demonstrations emphasize the 
integration of multiple vendors’ systems based on the IHE Technical Framework. 

1 .5 Year 2 Scope Additions 

This document refers to Year 2 of the IHE initiative. It will be the basis for demonstrations at 
RSNA 2000 and HIMSS 2001. The IHE Technical Framework: Year 2 adds the following 
primary features to those of previous years: 

• Images Available 

• Access to Radiology Information 

• Access to Non-Radiology Information 

• Patient Information Reconciliation 

• Consistent Presentation of Images 

• Report Management 

1.6 Comments 

HIMSS and RSNA welcome comments on this document and the IHE initiative. They should be 
directed to: 

Steve Drew/Chris Carr 
IHE secretary 
820 Jorie Boulevard 
Oak Brook, IL 60523 
Email: ihe@rsna.org 

1.7 Copyright Permission 

Health Level Seven, Inc., has granted permission to the IHE for reproducing tables from the HL7 
standard. The HL7 tables in this document are copyrighted by Health Level Seven, Inc. All 
rights reserved. 
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The National Electrical Manufacturers Association (NEMA) has granted permission to the IHE 
to incorporate portions of the DICOM standard. 

Material drawn from these documents is credited where used. 
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2 Conventions 

The IHE Technical Framework identifies actors which interact through transactions. Actors are 
information systems or components of information systems which produce, manage, or act on 
information associated with operational activities in the enterprise. Transactions are interactions 
between actors which transfer the required information through standards-based messages. 

2.1 The Generic IHE Transaction Model 

Transaction descriptions are provided in section 6. In each transaction description, the actors, the 
roles they play, and the transactions between them are presented as use cases. 

The generic IHE transaction description includes the following components: 

• Scope: a brief description of the transaction. 

• Use case roles: textual definitions of the actors and their roles, with a simple diagram 
relating them, e.g.: 



• Referenced Standards: the standards (HL7, DICOM, et. al.) to be used for the transaction. 

• Interaction Diagram: a graphical depiction of the actors and transactions, with related 
processing within an actor shown as a rectangle and time progressing downward, similar 
to: 
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Actor Actor Actor 



The interaction diagrams used in the IHE Technical Framework are modelled after those 
described in Grady Booch, James Rumbaugh, and Ivar Jacobson, The Unified Modeling 
Language User Guide, ISBN 0-201-57168-4. Simple acknowledgment messages are 
omitted from the diagrams for brevity. 

• Message definitions: descriptions of each message involved in the transaction, the events 
which trigger it, its semantics, the actions which it triggers in the receiver. 

2.2 DICOM Usage Conventions 

For some DICOM transactions described in this document, IHE has strengthened the 
requirements on the use of selected Type 2 and Type 3 attributes. These situations are explicitly 
documented in section 6 and in the appendices. 

IHE specifically emphasizes that DICOM Type 2 attributes (for instance, Patient Name, Patient 
ID) shall be transmitted with zero length if the source system does not possess valid values for 
such attributes; in other words, the source system shall not assign default values to such 
attributes. The receiving system must be able to handle zero-length values for such attributes. 

IHE has also defined requirements related to the support for and use of matching and return keys 
in DICOM queries by both Service Class Users (SCUs) and Service Class Providers (SCPs): 

• Required matching key : 

A key that the Query SCU shall have the ability to offer to its user as a selection 
criterion. The definition of the means offered to the user of the Image Display to 
trigger the sending of a matching key in the Query request is beyond the scope of 
IHE. The Query SCP uses a required matching key as a selection criterion in 
matching instances for return to the SCU in the query responses. 

• Required return key : 

A key that the Query SCU requests from the Query SCP, receives in the query 
responses, and displays for the user, if required. The definition of the means offered 
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to the user of the Image Display to request a return key and to make it visible to the 
user is beyond the scope of IHE. 

Note: matching keys are used to select instances for return by the query SCP to the SCU, 
whereas return keys return specific data and are not used for matching. 

The following legend is used by tables in section 6 to specify key requirements for SCUs and 
SCPs: 

R Required by DICOM 

R+ Required IHE extension of the DICOM requirements 

R* Required return key which is not required to be displayed 

O Optional 

Table 2.2-1 provides an example table defining matching and return keys. 


Table 2.2-1. Images Query Matching and Return Keys 


Attributes Name 

Tag 

Query Keys Matching 

Query Keys Return 

Notes 

SCU 

SCP 

SCU 

SCP 

Study Level 

Study Date 

(0008,0020) 

R+ 

R 

R+ 

R 


Study Time 

(0008,0030) 

R+ 

R 

R+ 

R 


Accession Number 

(0008,0050) 

R+ 

R 

R+ 

R 


Patient name 

(0010,0010) 

R+ 

R 

R+ 

R 


Patient ID 

(0010,0020) 

R+ 

R 

R+ 

R 


Study ID 

(0020,0010) 

R+ 

R 

R+ 

R 


Study Instance UID 

(0020.000D) 

R+* 

R 

O 

R 


Modalities in Study 

(0008,0061) 

R+ 

R+ 

O 

R+ 


Referring 
Physician's Name 

(0008,0090) 

R+ 

R+ 

R+ 

R+ 


Study Description 

(0008,1030) 

O 

O 

O 

O 



2.3 HL7 Profiling Conventions 

The HL7 tables included in this document have been modified from the HL7 2.3.1 standard 
document. Such a modification is called a profile. Refer to the HL7 2.3.1 standard for the 
meanings of specific columns in the table. 

The profiling tables in this document leverage the ongoing HL7 profile definition. To maintain 
this specification at a generic level, the following differences have been introduced: 

• Message specifications do not indicate the cardinality of segments within a message. 

• For fields composed of multiple components, there is no indication of the size of each 
component. 
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• Where a table containing enumerated values is referenced from within a segment profile 
table, the enumerated values table is not always present. 

• The number of times a repeating field can repeat is not indicated. 

• The conditions which would require inclusion of conditional fields are not defined. 

The following terms refer to the OPT column, which has been profiled: 

R Required 

R2 This is an IHE extension. If the sending application has data for the field, it is 

required to populate the field. If the value is not known, the field may not be sent. 

O Optional 

C Conditional 

IHE requires that Z-segments be present in HL7 transactions only when defined by the IHE 
Technical Framework. 

Table 2.3-1 provides an example profile for an imaginary HL7 segment. Tables for real 
segments are copied from the HL7 2.3.1 standard with modifications made only to the OPT 
column. 


Table 2.3-1. Example HL7 Profile 


SEQ 

LEN 

DT 

OPT 

TBL# 

ITEM# 

ELEMENT NAME 

1 

1 

ST 

R 


xxOOl 

Element 1 

2 

4 

ST 

O 


xx002 

Element 2 

3 

180 

HD 

R2 


xx003 

Element 3 

4 

180 

HD 

C 


xx004 

Element 4 

5 

180 

HD 

O 


xx005 

Element 5 

6 

180 

HD 

R 


xx006 

Element 6 


2.4 HL7 Implementation Notes 

2.4.1 Network Guidelines 

The HL7 2.3.1 standard does not define a network communications protocol. The HL7 2.1 
standard defines lower layer protocols in an appendix. These definitions were moved to the 
Implementation Guide in 2.2 and subsequent versions but are not HL7 requirements. The IHE 
Framework makes these recommendations: 

1. Applications shall use the Minimal Lower Layer Protocol defined in appendix C of the 
HL7 Implementation Guide. 

2. An application that wants to send a message (initiate a transaction) will initiate a 
network connection to start the transaction. The receiver application will respond with 
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an acknowledgement or response to query but will not initiate new transactions on this 
network connection. 

2.4.2 Acknowledgment Modes 

Applications that receive HL7 messages shall send acknowledgments using the HL7 Original 
Mode (versus Enhanced Acknowledgment Mode). 

2.4.3 HL7 and DICOM Mapping Considerations 

Field lengths are explicitly defined in the DICOM standard, but an HL7 element might consist of 
multiple components which do not have a defined maximum length. It is recognized that there 
are some HL7 component lengths which could be longer than the DICOM attribute lengths. Data 
values for mapped fields are required not to exceed the smaller of either the HL7 or the DICOM 
field length definitions. Systems supporting alternative character sets must take into account the 
number of bytes per character in such sets. All systems are required to support the DICOM 
Default Character Set (ISO-IR 6 or ASCII). In addition, other character sets may be supported. 
Maintaining consistency of data encoded using alternative character sets is outside of scope of 
the IHE Technical Framework: Year 2. 

Value Representations are not explicitly addressed. Attention should be given to the mapping of 
the HL7 representation and the DICOM representation. Examples of these include Patient Name, 
dates, times, etc. 
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System Transactions Overview 

The System Transaction Overview (figure 3-1) identifies significant actors and the flow of 
information between them - the transactions - throughout the clinical process addressed by the 
IHE Technical Framework: Year 2. Product implementations may support more than one actor 
based on the grouping rules specified in the section 3.3. 
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.1 Actor Descriptions 

In the figure 3-1, ovals represent actors whose definitions are listed below. 

Acquisition Modality - A system that creates and acquires medical images, e.g. a Computed 
Tomography scanner or Nuclear Medicine camera. May also create Grayscale 
Softcopy Presentation States for the consistent viewing of images. 

ADT Patient Registration - A system responsible for adding and/or updating patient 

demographic and encounter information. In particular, registers a new patient with 
identification and sends the update to the Order Placer and Department System 
Database. 

Order Placer - A hospital or enterprise- wide system that generates orders for various 
departments and distributes those orders to the correct department. 

Department System Database - A database component of the department-based 

information system (for instance, Radiology or Laboratory) which stores all relevant 
data about patients, orders, and their fulfillment. 

Department System Scheduler/Order Filler - A department-based information system (for 
instance, Radiology or Laboratory) or its component that schedules (assigns) material 
and other resources so as to perform procedures according to orders it receives from 
external systems or through the user interface. 

External Report Repository Access - A system that performs retrieval of clinical reports 
containing information generated from outside the Radiology department and 
presented as DICOM Structured Reporting Objects. 

Image Archive - A system that provides long term storage of image and presentation data. 

Image Creator - A system that creates additional images and/or Grayscale Softcopy 

Presentation States and transmits the data to an Image Archive. It also makes requests 
for storage commitment to the Image Manager for the images and/or Presentation 
States previously transmitted and generates Performed Procedure Steps. 

Image Display - A system that offers browsing of patients’ studies with series of images. In 
addition, supports the retrieval of selected set of images and their presentation 
characteristics specified by modality (size, color, annotations, layout, etc.). 

Image Manager - A system that provides functions related to safe data storage and image 
data handling. It supplies image availability information to the Department System 
Scheduler. 

Master Patient Index - A system that maintains unique enterprise-wide identifier for a 
patient. 

Performed Procedure Step Manager - A system that provides a service of re-distributing 

the Modality Performed Procedure Step information from the Acquisition Modality or 
Image Creator to the Department System Scheduler/Order Filler and Image Manager 
actors. 

Print Composer -A system that generates DICOM print requests to the Print Server Actor. 
Print requests include presentation state information in the form of Presentation 
Look-Up Tables (Presentation LUTs). 
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Print Server - A system that accepts and processes DICOM print requests as a DICOM 
Print SCP and performs image rendering on hardcopy media. The system must 
support pixel rendering according to the DICOM Grayscale Standard Display 
Function. 

Report Creator - A system that generates and transmits draft (and optionally, final) reports, 
presenting them as DICOM Structured Reporting Objects. 

Report Manager - A system that provides functions related to report management. This 
involves the ability to handle content and state changes to reports and to create new 
DICOM Structured Reporting Objects based on these changes. 

Report Reader - A system that can query/retrieve and view reports presented as DICOM 
Structured Reporting Objects. 

Report Repository - A system that provides long-term storage of reports and their retrieval 
as DICOM Structured Reporting Objects. 

.2 Transaction Descriptions 

This section describes the transactions found in figure 3-1. The transaction numbers and titles 
correspond those of the figure. 

1. Patient Registration - The patient is registered/admitted. This will generate a visit or 
encounter event as well as a registration event if the patient is not pre-existing. 

2. New Order - An order is created via an order entry system (Order Placer); an order 
may contain procedures that cross multiple departments. Department-specific orders/ 
procedures are forwarded to the appropriate department. The Order Filler informs an 
Order Placer about the order’s status changes. An order may also be generated by the 
Order Filler in a department and submitted to the Order Placer. 

3. Order Cancel - A previously placed order is terminated or changed. Either the Order 
Placer or the Departmental System Scheduler/Order Filler may need to change order 
information or cancel/discontinue an order. When order information change is 
necessary, the IHE Technical Framework: Year 2 requires that initiatorcancel the order 
and generate the new one using new information. All systems that are aware of the 
order are informed of the change, including the Image Manager if the order has been 
scheduled as one or more procedures. 

4. Procedure Scheduled - Schedule information is sent from the DSS/Order Filler to the 
Image Manager. 

5. Modality Worklist Provided - Based on a query entered at the Acquisition Modality, 
a modality worklist is generated listing all the items that satisfy the query. This list of 
Scheduled Procedure Steps with selected demographic information is returned to the 
Acquisition Modality. 

6. Modality Procedure Step In Progress - An Acquisition Modality notifies the 
Performed Procedure Step Manager of a new Procedure Step. 
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7. Modality Procedure Step Completed - An Acquisition Modality notifies the 
Performed Procedure Step Manager of the completion of a Procedure Step. 

8. Modality Images Stored - An Acquisition Modality requests that the Image Archive 
store acquired or generated images. 

9. Modality Presentation State Stored - An Acquisition Modality requests that the 
Image Archive store the Grayscale Softcopy Presentation State (GSPS) for the acquired 
or generated images. 

10. Modality Storage Commitment - An Acquisition Modality requests that the Image 
Manager take responsibility for the specified images and/or GSPS objects the 
Acquisition Modality stored. 

11. Images Availability Query - The Department System Scheduler/Order Filler asks the 
Image Manager if a particular image or image series is available. 

12. Patient Update - The ADT Patient Registration System informs the Order Placer and 
the Department System Scheduler/Order Filler of new information for a particular 
patient. The Department System Scheduler may then further inform the Image 
Manager. 

13. Procedure Update - The Department System Scheduler/Order Filler sends the Image 
Manager updated order or procedure information. 

14. Query Image - An Image Display provides a set of criteria to select the list of entries 
representing images by patient, study, series, or instance known by the Image Archive. 

15. Query Presentation State - An Image Display provides a set of criteria to select the 
list of entries representing image Grayscale Softcopy Presentation States (GSPS) by 
patient, study, series, or instance known by the Image Archive. 

16. Retrieve Images - An Image Display requests and retrieves a particular image or set of 
images from the Image Archive. 

17. Retrieve Presentation States - An Image Display requests and retrieves the Grayscale 
Softcopy Presentation State (GSPS) information for a particular image or image set. 

18. Creator Images Stored - An Image Creator requests that the Image Archive store new 
images. 

19. Creator Presentation State Stored - An Image Creator requests that the Image 
Archive store the created Grayscale Softcopy Presentation State objects. 

20. Creator Procedure Step In Progress - An Image Creator notifies the Performed 
Procedure Step Manager of a new Procedure Step. 

21. Creator Procedure Step Completed - An Image Creator notifies the Performed 
Procedure Step Manager of the completion of a Procedure Step. 

22. Creator Storage Commitment - An Image Creator requests that the Image Manager 
take responsibility for the specified images and/or GSPS objects that the Creator 
recently stored. 
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23. Print Request with Presentation LUT - A Printer Composer sends a print request to 
the Print Server specifying Presentation LUT information. 

24. Report Submission - A Report Creator sends a draft or final report to the Report 
Manager. 

25. Report Issuing - A Report Manager sends a draft or final Report to the Report 
Repository. 

26. Query Report - A Report Reader provides a set of criteria to select the list of entries 
representing reports by patient, study, series, or report known by the Report Repository 
or External Report Repository Access. 

27. Retrieve Report - A Report Reader requests and retrieves a report from the Report 
Repository or External Report Repository Access. 
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3.3 Grouping of Actors 

The actors identified in figure 3-1 may be selected individually or in any combination by product 
implementations. However, in cases explicitly specified below, the selection of one actor 
requires an implementation to select one or more additional actors: 

1. The Image Archive shall be grouped with the Image Manager and Performed Procedure 
Step Manager. 

2. The Performed Procedure Step Manager shall be grouped with either an Image 
Manager or a Department System Scheduler. 

3. The Print Composer shall be grouped with either an Image Manager, an Acquisition 
Modality, an Image Display or an Image Creator. 

4. The Image Creator shall be grouped with an Image Display. This is a uni-directional 
requirement - the Image Display does not have to be grouped with any other actor. 

5. The Order Filler/Department System Scheduler shall be grouped with the Department 
System Database and Performed Procedure Step. 

When multiple actors are supported by a single product implementation, all transactions 
originating or terminating with each of the supported actors shall be supported (i.e., the IHE 
transactions shall be offered on an external product interface). The exceptions to this rule are the 
transactions defined between actors in the required groupings defined above (some may have no 
transactions between them) that do not need to be offered on an external interface. 

Note: For example, the Procedure Step In Progress/Completed transaction does not need to 
be supported between the Performed Procedure Step Manager and the Image manager 
when these are grouped. On the other hand, the Report Submission Transaction must 
be supported even by an implementation that groups the Report Creator and the 
Report Manager Actors. 

When two or more actors are grouped together, internal communication between actors is 
assumed to be sufficient to allow the necessary information flow to support their functionality; 
for example, the Image Manager provides necessary information updates to the Image Archive to 
support its Query/Retrieve functionality. The exact mechanisms of such internal communication 
are outside of the scope of IHE Technical Framework. 

3.4 Actor Requirements Overview 

The tables below summarize the requirements for each of the actors which are part of the IHE 
Framework in terms of the transactions they must support. Some of the tables relate to a single 
actor; others, to groups of actors. In every case, the tables are in line with the grouping rules 
specified in section 3.3. This set of tables is not intended to include all possible actor groupings 
but merely a representative subset. Notes provide clarification and reference to applicable 
sections of the document wherever necessary. 
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Some tables include the contents of other tables. This inclusion means that the rows and columns 
of the referenced table (excluding headings) and all tables it includes are prepended to the 
referencing table. Table inclusion was not used for tables which shared actors (e.g. Image 
Archive/Image Manager and Image Archive/Image Manager/Performed Procedure Step 
Manager) but had different requirements for common transactions (e.g. Modality Procedure Step 
In Progress). 

These tables provide a condensed view of actor requirements; for full detail and context of these 
requirements, read the subsections of section 6. 


Table 3.4-1. Acquisition Modality 


Transaction 

Optionality 

Notes 

Modality Worklist Provided 

Required 

Must support patient-based or broad query. See section 6.5 

Modality Images Stored 

Required 


Modality Storage Commitment 

Required 


Modality Procedure Step In 
Progress 

Required 

See section 6.6 for Protocol and Procedure code options 

Modality Procedure Step 
Completed 

Required 


Modality Presentation State 
Stored 

Optional 



Table 3.4-2. Acquisition Modality/Print Composer 


Transaction 

Optionality 

Notes 


Include contents of table 3.4-1 Acquisition Modality 

Print Request with Presentation 
LUT 

Required 



Table 3.4-3. ADT Patient Registration 


Transaction 

Optionality 

Notes 

Patient Registration 

Required 


Patient Update 

Required 



Table 3.4-4. Image Archive/Image Manager/Performed Procedure Step Manager 


Transaction 

Optionality 

Notes 

Modality Images Stored 

Required 


Modality Presentation State 
Stored 

Required 


Modality Procedure Step In 
Progress 

Required 
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Modality Procedure Step 
Completed 

Required 


Modality Storage Commitment 

Required 


Creator Images Stored 

Required 


Creator Presentation State 
Stored 

Required 


Creator Procedure Step in 
Progress 

Required 


Creator Procedure Step 
Completed 

Required 


Creator Storage Commitment 

Required 


Query Images 

Required 

Must support Study Root Query/Retrieve - FIND SOP class as SCP. 
May support Patient Root Query/Retrieve - FIND SOP class as SCP. 
See section 6.14 

Query Presentation State 

Required 

Must support Study Root Query/Retrieve - FIND SOP class as SCP. 
May support Patient Root Query/Retrieve - FIND SOP class as SCP. 
See section 6.15 

Retrieve Images 

Required 

Must support Study Root Query/Retrieve - MOVE SOP class as SCP. 
May support Patient Root Query/Retrieve - MOVE SOP class as SCP. 
See section 6.16 

Retrieve Presentation State 

Required 

Must support Study Root Query/Retrieve - MOVE SOP class as SCP. 
May support Patient Root Query/Retrieve - MOVE SOP class as SCP. 
See section 6.17 

Procedure Scheduled 

Required 


Image Availability Query 

Required 


Patient Update 

Required 


Procedure Update 

Required 



Table 3.4-5. Image Archive/Image Manager/Performed Procedure Step Manager/Print 

Composer 


Transaction 

Optionality 

Notes 

Include contents of table 3.4-4 Image Archive/Image Manager/Performed Procedure Step Manager 

Print Request with Presentation 
LUT 

Required 



Table 3.4-6. Department System Scheduler/Order Filler/Department System 
Database/Performed Procedure Step Manager 


Transaction 

Optionality 

Notes 

New Order 

Required 


Order Cancel 

Required 


Modality Worklist Provided 

Required 

Must support patient-based or broad query. See section 6.5 
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Modality Procedure Step In 
Progress 

Required 


Modality Procedure Step 
Completed 

Required 


Creator Procedure Step in 
Progress 

Required 


Creator Procedure Step 
Completed 

Required 


Image Availability Query 

Required 


Patient Registration 

Required 


Patient Update 

Required 


Procedure Scheduled 

Required 


Procedure Update 

Required 



Table 3.4-7. Image Display 


Transaction 

Optionality 

Notes 

Query Images 

Required 

Must support Study Root Query/Retrieve - FIND SOP class as SCU. 
May support Patient Root Query/Retrieve - FIND SOP class as SCU. 
See section 6.14 

Query Presentation State 

Optional 


Retrieve Images 

Required 

Must support Study Root Query/Retrieve - MOVE SOP class as SCU. 
May support Patient Root Query/Retrieve - MOVE SOP class as SCU. 
See section 6.16 

Retrieve Presentation State 

Optional 



Table 3.4-8. 

Image Display/Image Creator 

Transaction 

Optionality 

Notes 

Include contents of table 3.4-7 Image Display 

Creator Images Stored 

Required 


Creator Presentation State 
Stored 

Required 

Must support Image Storage or GSPS Storage or both as SCU 

Creator Storage Commitment 

Required 


Creator Procedure Step in 
Progress 

Optional 


Creator Procedure Step 
Completed 

Optional 


Table 3.4-9. Image Display/Image Creator/Print Composer 

Transaction 

Optionality 

Notes 
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Include contents of table 3.4-8 Image Display/Image Creator 


Print Request with Presentation 

Required 


LUT 




Table 3.4-10. External Report Repository Access 


Transaction 

Optionality 

Notes 

Query Report 

Required 

Must support Study Root Query/Retrieve - FIND SOP class as SCP. 
May support Patient Root Query/Retrieve - FIND SOP class as SCP. 
See section 6.26 

Retrieve Report 

Required 

Must support Study Root Query/Retrieve - MOVE SOP class as SCU. 
May support Patient Root Query/Retrieve - MOVE SOP class as SCU. 
Must support Basic Text SR Storage SOP class as SCU. May support 
Enhanced SR Storage SOP class as SCU. See section 6.27 


Table 3.4-11. Order Placer 


Transaction 

Optionality 

Notes 

Patient Registration 

Required 


New Order 

Required 


Order Cancel 

Required 


Patient Update 

Required 



Table 3.4-12. Print Server 


Transaction 

Optionality 

Notes 

Print Request with Presentation 
LUT 

Required 



Table 3.4-13. Report Creator 


Transaction 

Optionality 

Notes 

Report Submission 

Required 

Must support Basic Text SR Storage SOP class Enhanced SR Storage 
SOP class or both as SCU. See section 6.24 


Table 3.4-14. Report Manager 


Transaction 

Optionality 

Notes 

Report Issuing 

Required 

Must support Basic Text SR Storage SOP class as SCU. If Enhanced 
SR Storage SOP class is supported as SCP for Report Submission 
transaction then must support Enhanced SR Storage SOP class as SCU. 
Otherwise, may support Enhanced SR Storage SOP class as SCU. See 
section 6.24 

Report Submission 

Required 

Must support Basic Text SR Storage SOP class as SCP. May support 
Enhanced SR Storage SOP class as SCP. See section 6.25. 


21 


Rev. 4.0 Copyright © 2000: HIMSS/RSNA 

03-28-2000 









IHE Technical Framework: Year 2 


Table 3.4-15. Report Reader 


Transaction 

Optionality 

Notes 

Query Report 

Required 

Must support Study Root Query/Retrieve - FIND SOP class as SCU. 
May support Patient Root Query/Retrieve - FIND SOP class as SCU. 
See section 6.26 

Retrieve Report 

Required 

Must support Study Root Query/Retrieve - MOVE SOP class as SCU. 
May support Patient Root Query/Retrieve - MOVE SOP class as SCU. 
Must support Basic Text SR Storage SOP class as SCP. May support 
Enhanced SR Storage SOP class as SCP. See section 6.27 


Table 3.4-16. Report Repository 


Transaction 

Optionality 

Notes 

Report Issuing 

Required 

Must support both Basic Text SR Storage SOP class and Enhanced SR 
Storage SOP class as SCP. See section 6.24 

Query Report 

Required 

Must support Study Root Query/Retrieve - FIND SOP class as SCU. 
May support Patient Root Query/Retrieve - FIND SOP class as SCU. 
See section 6.26 

Retrieve Report 

Required 

Must support Study Root Query/Retrieve - MOVE SOP class as SCU. 
May support Patient Root Query/Retrieve - MOVE SOP class as SCU. 
Must support both Basic Text SR Storage SOP class and Enhanced SR 
Storage SOP class as SCU. See section 6.27 
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4 The IHE Data Model 

4.1 Scope 

This section defines the integrated data model adopted by the IHE Technical Framework for the 
HL7 messages and the DICOM Information Object Definitions (IODs). The Entity Relationship 
(ER) diagram represents the integration of proper subsets of HL7 2.3.1 and the DICOM Model 
of the Real World with minor extensions as noted in section 1 and described in appendix B. 

4.2 Model of the Real World 

Figure 4.2-1 depicts the model of real world within scope of the IHE Technical Framework: Year 
2. This model provides an overview of the high-level integration of the DICOM and HL7 
models. This integrated model differs from the DICOM Model of the Real World (refer to 
DICOM 1999 PS 3.3) in the following aspects: 

• The Service Episode, Procedure Plan and Procedure Type entities as well as the 
relationship between the Visit and Imaging Service Request have been excluded; these 
entities and relationships are outside the scope of the IHE Technical Framework: Year 2. 

• The HL7 Placer Order entity has been inserted into the DICOM hierarchy between the 
Patient entity and Imaging Service Request Entity. 

• The DICOM Imaging Service Request Entity is equated with the HL7 Filler Order entity. 
In this relationship IHE provides clarification of the use of the Accession Number - 
DICOM attribute (0008,0050); see appendix A for further discussion. 
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Figure 4.2-1 : Model of the Real World for IHE Integrated Information 


4.3 The IHE Information Model 

The IHE Information Model is represented in this section as an Entity Relationship (ER) 
diagram. The IHE Information Model is based on the DICOM and HL7 standards. The keys 


Rev. 4.0 
03-28-2000 


24 


Copyright © 2000: HIMSS/RSNA 













IHE Technical Framework: Year 2 

relating the entities and the unique keys of each entity are defined and the cardinality of the 
entities is indicated. 

An example of the conventions used to specify an entity’s relationship is given in figure 4.3-2. 



Entity Name 

Foreign Key (FK) relating this entity to previous - The FK is shown to clarify the ER diagram and not 
intended to represent a relational model. 

Unique Key (U) for this entity. There are cases where Unique keys that are identical within the scope of 
this document have different contextual meanings, as defined in this document. The "+" symbol 
indicates two attributes must be combined to guarantee uniqueness. 

Figure 4.3-2. Example of the Entity Relationship Diagram 
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Performed Procedure To Scheduled 

Step Entity Procedure Step 

Figure 4.3-3. IHE Information Model (part 1) 

Figure 4.3-3 contains the overview of the IHE Information Model. See section 2 of this 
document for HF7 and DICOM mapping considerations. Mappings between specific HF7 
Elements and DICOM Attributes are identified in appendix D. 
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FromRequested Procedure Step 



Figure 4.3-3. IHE Information Model (part 2) 
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5 Enterprise Process Flows 

This section describes typical examples of the process and information flows of patient care in 
healthcare enterprise. Examples are used to highlight the principles and strategies adopted by the 
IHE Technical Framework and are not intended to provide an exhaustive set of supported 
process and workflow patterns. The examples consider the use of a single instance of each actor 
whereas real-life situations might require multiple instances of some actors. 

Process Flow diagrams shown in subsequent sections illustrate the flow of processes and 
interactions among the actors involved in a particular example. These diagrams are constructed 
similar to those for interaction diagrams (see section 2 and figure. 5-1). 

Note: The Performed Procedure Step Manager is not shown on the Process Flow diagrams 
and is presumed to be grouped with the Image Manager. It may be grouped with the 
Department System Scheduler/Order Filler with corresponding changes in the flow of 
PPS related transactions between the Image Manager and Department System 
Scheduler/Order Filler. 


Actor Actor Actor 



Time 


Figure 5-1. Example of Process Flow Diagram 

Note 1: The actors involved are displayed on the vertical axes. The vertical axis identifies 
the timeline with time increasing from the top of the axis downward. 

Note 2: An arrow between two actors identifies a transaction. Transaction names above the 
arrows are followed (in the square brackets) by transaction numbers outlined in 
section 3.3. 

Note 3: Names printed in italics indicate internal processes that do not have an IHE defined 
transaction associated with them. 

5.1 Typical Process Flow 

This section describes process and information flow of the patient care as it is defined in the IHE 
Technical Framework: Year 2 under “normal” circumstances. It covers transactions 1 through 13 
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and transaction 23 which reflect typical patient encounter from the registration/admission 
through the performance of an ordered procedure. See appendix F for the overview of the 
information exchange between DS S/Order Filler and Image Manager. 

5.1.1 Administration and Procedure Performance Process Flow 

This case covers both inpatient and outpatient procedures. The patient may be new or known to 
the current healthcare facility. The following sequence of steps describes the typical process flow 


when a procedure is requested to be performed on a patient. 



Order 

Department System 

Image 

Acquisition 

ADT Placer 

Database/Scheduler/ 

Manager 

Modality 


Order Filler 



1 Register/ 1 


1 

I 

Admit | 

I 

1 

1 

1 

1 

1 

I 

1 

1 

4 Patient 

1 

I 

1 

1 

1 

I 


Patient 

Registration [1] 



Figure 5.1-1. Administrative Process Flow 
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Department System 
Database/Scheduler/ 
Order Filler 


Image 

Manager 


Acquisition 

Modality 


Image 

Archive 


Print 

Server 


Modality Procedure 
Step In Progress [6] 


Modality Procedure 
Step In Progress [6] 


Modality Procedure 
Step Completed [7] 

H 


Modality Procedure 
Step Completed [7] 

14 


1 . 1 Modality Storage 

Commitment [ 10] 

<4 


Images Availability 
Query [11] 


Print 

Composer 


Perform 
Acquisition 

Modality Images 
Stored [8] 


Modality 
Presentation State 
Stored [9] 


Print Request [23] 


Figure 5.1-2. Procedure Performance Process Flow 

The following should be noted in relation to the Administrative and Procedure Performance 
process flow: 

• The Print Composer is grouped with an Acquisition Modality but is shown separately in 
the diagram to distinguish the different transactions. 

• Schedule Procedure. The order is associated with a number of procedures that have to be 
performed to satisfy the order. Each procedure prescribes a number of action items that 
have to be performed by the Acquisition Modality. Action items may be grouped into 
Scheduled Procedure Steps based on the timing and ordering. Scheduled Procedure Steps 
are scheduled, i.e., assigned a time slot and performing resource (modality). 

• Protocol Assigned. The radiologist determines the protocol, i.e., settings and conditions 
to be used in performing procedure steps. This may happen before, simultaneously with 
or subsequent to the Schedule Procedure process step. 

• The diagram above shows one particular sequencing of the Performed Procedure Step 
“Completed” transaction. This transaction may occur at any point after image and/or 
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GSPS creation. This means it can occur before images and/or GSPS are stored, after 
storage, after printing as in this example, or even after storage commitment. The IHE 
Technical Framework does not specify the timing of this transaction in relation to other 
transactions. 


5.1.2 Patient Update Flow 

This case covers the situation when patient information updates are introduced into the system at 
the different stages of the normal process flow. Such updates will cause additional transactions to 
occur to assure synchronization of information between interested actors. Only the affected parts 
of the normal flow diagram are presented below. All subsequent process steps will progress 
according to the normal flow diagram. 


5.1. 2.1 Patient Update Before Procedure Scheduling 


If patient information is changed before the corresponding procedure(s) are scheduled by the 
DSS/Order Filler, the Patient Registration steps are altered as presented in the figures 5.1-3 and 


5.1-4. 


ADT 


Register/ 

Admit 

Patient 


Order Department System 

Placer Database/Scheduler/ 

Order Filler 


Image 

Manager 


Patient 


Registration [1] 


Modify 

Patient 


Patient ! 


1 

Patient Update [12] 

— 1 — 

Update [12] 


1 * 


► 


► 


1 

1 

1 


1 

1 


Create 

Order 


New Order [2] 


Acquisition 

Modality 


Figure 5.1-3. Patient Update before Order Entry 
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ADT 


Order Department System Image 

Placer Scheduler/ Order Filler Manager 


Acquisition 

Modality 



Figure 5.1-4. Patient Update after Order Entry 

The Modify Patient process includes changing inpatient demographics, merging two patient 
records and moving the information from one patient record to another. 

.1.2.2 Patient Update After Procedure Scheduling 

If patient information is changed after procedure(s) are scheduled by the Order Filler, the Patient 
transactions altered as follows: 


Rev. 4.0 
03-28-2000 


32 


Copyright © 2000: HIMSS/RSNA 











IHE Technical Framework: Year 2 


Image Acquisition 

Manager Modality 


Patient 

Registration [ 1] 



I I 

I I 


Figure 5.1-5. Patient Update After Procedure Scheduling 

In addition to the information exchange between ADT, Order Placer and DS S/Order Filler 
actors, Patient Update information is also sent to the Image Manager. It is the responsibility of 
the Image Manager to ensure that the patient information is updated in the images and Grayscale 
Softcopy Presentation State objects when they are retrieved from the Image Archive. 

5.1.3 Order Change Flow 

This case covers the situation when the Order Placer or the DSS/Order Filler has to change order 
information or cancel/discontinue an order. When order information change is necessary, IHE 
Technical Framework: Year 2 requires the initiating actor to cancel the order and generate the 
new one using the new information, figures 5.1-6 and 5.1-7 depict examples of order 
cancellation/re-ordering flow initiated by the Order Placer and the DSS/Order Filler respectively. 
Note that one should consider these transactions as being performed between the process flow 
fragments depicted in the figures 5.1-1 and 5.1-2 to ensure synchronization of information 
between interested actors. 
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ADT 


Order 

Placer 


Department System 
Database/Scheduler/ 
Order Filler 


Image 

Manager 


Modality 



Image Archive 


Figure 5.1-6. Order Replacement by the Order Placer 

DSS/Order Filler may cancel an order received from the Order Placer and place the new order as 
a replacement, as shown in the figure 5.1-7. 
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ADT 


Order 

Placer 


Department System 
Database/Scheduler/ 
Order Filler 


Image 

Manager 


Modality 



Image Archive 


Figure 5.1-7. Order Replacement by the DSS/Order Filler 

The DSS/Order Filler may also generate a new order on its own as a means of handling the 
unidentified patient case discussed in section 5.4. The process flow in such situation corresponds 
to the ordering sequence in figure 5.1-7, without the preceding Order Cancel transaction. 

Note: The IHE Technical Framework: Year 2 does not support notification of the modality 
of the order discontinuation after the Modality Procedure Step In Progress message 
has been generated by the Acquisition Modality, i.e., the current procedure step will 
be completed even though the order could be discontinued. 
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5.2 Enterprise Access and Creation of Imaging Information 

This section describes the typical process flow related to viewing images with Grayscale 
Softcopy Presentation States and performing image post-processing that may generate new 
images and/or Grayscale Softcopy Presentation States. The transactions covered are 14 through 
22 . 

5.2.1 Scope 

Enterprise Access to Imaging Information is an integration feature that provides access to images 
with their full fidelity content as they were acquired or created. Such access is available either: 

• Internally to the source imaging department; 

• Between imaging departments (e.g., Cardiology and Radiology); or 

• Throughout the Healthcare Enterprise to other departments or care providers other than 
an imaging department (e.g., Surgery, Neurology, Oncology). 

Enterprise Access to Imaging Information enables advanced review as well as simple or 
sophisticated post-processing of images along with related objects (such as Grayscale Softcopy 
Presentation States, or Structured Reports) in a variety of clinical scenarios. Examples are: 

• Based on patient identifying information, a clinician wishes to look for imaging studies 
performed on this patient. The clinician may access one or more series of images, related 
to a recent examination; 

• A radiologist performing a primary or secondary read wishes to retain viewing 
parameters including clinical annotations; 

• A clinician reviewing a report that references key images wishes to review these images; 

• A technologist about to perform an imaging examination wishes to retrieve a prior 
imaging examination for ensuring consistent patient positioning; 

• A radiologist interpreting a study wishes to perform a comparison with images acquired 
in a prior study. The radiologist also needs to review the images as they were presented 
when a prior diagnosis was prepared; 

• A surgeon creates a 3D volume analysis of an image set to plan surgery on a patient. 

5.2.2 Consistent Presentation of Images 

The appearance of grayscale images displayed on different types of softcopy display devices or 
printed by different types of hardcopy output devices has often been inconsistent. To address this 
problem and achieve consistent presentation of grayscale images the DICOM Standard defines: 

• A standard curve, the Grayscale Standard Display Function, against which different types 
of display and hardcopy output devices should be calibrated; 

• Basic Print Management with Presentation Look Up Table, for controlling the consistent 
appearance of preformatted images on printed output; 

• Grayscale Softcopy Presentation State, an object for storing and communicating the 
parameters that describe how an image or set of images should be displayed. A Grayscale 
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Softcopy Presentation State object contains references to the images it applies to, and the 
transformations (grayscale transformations, shutter transformations, image annotation, 
spatial transformations, and display area annotation) that should be applied when the 
images are presented on a softcopy display. 

These capabilities are supported by the IHE Technical Framework. Their typical use is depicted 
in figure 5.2-1. Another use case is described in section 5.5. 
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Creator Procedure Step In Progress [20] 
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Creator Presentation State Stored [19] 
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Filler 


Creator Procedure Step In 
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Creator Procedure Step 
Completed [21] 



Figure 5.2-1. Enterprise Access and Creation of Imaging Information Process Flow 

The following shall be taken into account in relation to the Enterprise Access and Creation of 
Imaging Information Flow: 

• The Image Creator Actor shall be grouped with an Image Display Actor but is shown 
separately in the diagram above to distinguish the transactions; 
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• In this example, the Print Composer Actor is grouped with the Image Creator Actor but 
may be grouped with other actors that have access to images; 

• The diagram above shows one particular sequencing of the Performed Procedure Step 
“Completed” transaction. This transaction may occur at any point after image and/or 
GSPS creation. This means it can occur before images and/or GSPS are stored, after 
storage, after printing as in this example, or even after storage commitment. The IHE 
Technical Framework does not specify the timing of this transaction in relation to other 
transactions. 

5.3 Diagnostic Reporting 

This section describes the typical process flow related to diagnostic reporting. The transactions 
covered are 24 through 27. 

5.3.1 Scope 

In the initial stage of diagnostic reporting, the diagnosis by the Radiologist is used to generate a 
DICOM Structured Report object which is submitted to the Report Manager. Once a report is 
sent to the Report Manager, the Report Creator relinquishes control of the report to the Report 
Manager. 

Reports are processed and modified by the Report Manager. This involves adding and changing 
report data as well as verifying draft reports. In all cases, any change by the Report Manager 
leads to the creation of a new DICOM Structured Report object. At any time, the Report 
Manager can transmit reports to the Report Repository for external access, but at a minimum the 
final report must be sent to the Report Repository. 

The Report Repository provides permanent storage of DICOM Structured Reports. It also allows 
reports to be queried and retrieved throughout the enterprise by Report Readers. A Report 
Reader provides a user interface to view DICOM Structured Reports that it retrieves from the 
Report Repository or External Report Repository Access. 

The External Report Repository Access is a “gateway” to obtain other enterprise department 
reports, such as Laboratory and Pathology, from within the Radiology department. DICOM 
Structured Reports are queried and retrieved by a Report Reader from the External Report 
Repository Access. 
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Figure 5.3-1. Diagnostic Reporting Process Flow 
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5.3.2 Diagnostic Reporting Use Cases 

DICOM Structured Reports offer the capability to encode diagonstic report data structured in an 
arb it ary way. The IHE Technical Framework stipulates that the reporting actors need to support 
several use cases and their specific content patterns, which are detailed in the following sections. 
The diagrams in the sections define the report content pattern and utilize the following 
conventions: 

• Each rectangle is a single Content Item. 

• Bold text in a rectangle denotes the Code Meaning from the Concept Name Code 
Sequence. 

• Italic text in a rectangle denotes a generic grouping of Concept Names to be used for the 
Content Item. These must be configurable in the reporting actors. 

• Uppercase text in a rectangle denotes the Content Item Value Type. 

• Text following the Content Item Value Type specifies the possible Content Item 
Value(s), if known (only used for Observation Context). 

• Text on lines defines the relationship between Content Items. 

• Numbers on lines defines the cardinality of descendent Content Items. 

5.3.2.1 Key Image Note 

The Key Image Note allows the association of a textual description with a list of image 
references. This content pattern is shown in figure 5.3-2 and shall use the DICOM Basic Text SR 
Information Object Definition. 


Observation Context 
(See Figure 5.3-5) 


Figure 5.3-2. Key Image Note Pattern 
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5. 3. 2. 2 Simple Image Report 

The Simple Image Report allows documents with multiple sections (with headings) containing 
report text and references to relevant images. Some text items of these documents may also be 
related to specific images. This allows a radiologist to identify one or more images from which 
their conclusions were inferred. This content pattern is shown in figure 5.3-3 and shall use the 
DICOM Basic Text SR Information Object Definition. 



Figure 5.3-3. Simple Image Report Pattern 
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5. 3. 2. 3 Simple Image and Numeric Report 

The Simple Image and Numeric Report is similar to the Simple Image Report described in 
section 5. 3. 2. 2 but allows the addition of numeric values. This enables a diagnosis to include 
measurements and other numeric values. Like the Simple Image Report, particular text values 
can be encoded to signify that they are inferred from specific images or numeric values. The 
Simple Image and Numeric Report pattern is shown in figure 5.3-4 and shall use the DICOM 
Enhanced SR Information Object Definition. 



Figure 5.3-4. Simple Image and Numeric Report Pattern 
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.3.2.4 Observation Context 

For each of the preceding report patterns, observation context shall be included according to the 
pattern shown in figure 5.3-5. This list of content items specify such information as the type of 
observation (only “DIRECT” is allowed), the name of the recording observer and their 
organization, the name of the patient, and links to the procedure that is being reported upon. 

Observation context content items shall only be descended from the root content item, and this 
observation context is inherited by all other nodes descended from the root node. Therefore, the 
observation context shall not change thoughout the report. 


Rev. 4.0 
03-28-2000 


44 


Copyright © 2000: HIMSS/RSNA 



IHE Technical Framework: Year 2 


Document Title 
(CONTAINER) 



* - “Patient-Data- Acquisition Subject” and “Mother of 
fetus” are mutually exclusive based on the value of 
“Observation Subject Class” and one and only one item 
shall appear 


Figure 5.3-5. Observation Context Pattern 

5.4 Unidentified Patient Image Acquistion & Reconciliation 

This section describes the general process flow related to the handling of procedures for 
unidentified patients. The transactions covered are 1, 2, 4, 5, 6, 7, 12, and 13. 

5.4.1 Scope 

The Unidentified Patient case covers the trauma case or emergency room patient when a 
patient’s condition requires that a procedure is conducted immediately. This is done before 
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proper patient registration, ordering and/or scheduling of the procedure is performed (due to the 
lack of either information or time or other deviation from the normal process flow). In this case 
patient/study information must be later reconciled and properly updated at the ADT, Order 
Placer, DSS/Order Filler and Image Manager. There are several examples of information flow in 
this case. These examples are described in use cases (see sections 5.4.2. 1 - 5. 4. 2. 3 for details): 

• Case 1 : Unidentified Patient registered at ADT and ordered at Order Placer. 

• Case 2: Unidentified Patient registered at ADT and ordered at DSS/Order Filler. 

• Case 3: Unidentified Patient registered at ADT but acquisition completed at Modality 
prior to order. 

In cases 1, 2, and 3, the ADT may utilize the Master Patient Index (MPI) internally. The 
interaction of the ADT with MPI to resolve the patient information to the correct Patient ID may 
be embedded in the process of patient information reconciliation within the ADT role. The IHE 
Technical Framework in future years may define patient reconciliation transactions using MPI. 

The IHE Technical Framework: Year 2 also supports cases when registration or temporary 
registration of a patient by ADT is not applicable or desired, for example: 

• Emergency Department patient who can be identifid themselves but due to constraints 
requires the procedure to be performed before proper order entry and scheduling may 
occur. 

• Patient ID, though valid, has never been propagated to all actors due to communication 
failures, or the wrong Patient record was used in ordering/scheduling. 

• Patient ID, though valid, has been mistyped at the modality. 

The following additional use cases are identified (see sections 5.4. 2. 4 and 5.4. 2. 5): 

• Case 4: Unidentified Patient assigned temporary Departmental ID and scheduled at 
DSS/Order Filler 

• Case 5: Image Acquisition completed prior to assigning temporary Departmental ID or 
Order 

Cases 4 and 5 require patient reconciliation on the department level. In the case of procedures 
performed on the unidentified patient in multiple departments (e.g.. Radiology and Faboratory), 
this will require reconciliation of patient information in multiple locations. To address this issue, 
the IHE Technical Framework in future years may define patient reconciliation transactions 
using Master Patient Index (MPI). 

Note: 

The IHE Technical Framework: Year 2 also recognizes that the following case of handling 
unidentified patients may be utilized in certain installations: 

• The patient is delivered to the department where it is assigned a temporary 
departmental Patient ID and/or name. 

• The order is then entered by the DSS/Order Filler and with this Patient ID and/or 
name, the procedure is performed on the Acquisition Modality. 
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• The DSS/Order Filler sends a new order transaction to the Order Placer. Thus this 
departmental Patient ID will be shared by Image Manager, DSS/Order Filler and 
Order Placer. However, this departmental Patient ID will not be known to the ADT. 

• After resolution of the patient identity, the ADT registers/admits patient with the 
correct Patient ID and sends a message to the Order Placer and DSS/Order Filler. 

Each system must locally merge the new record with the existing one identified by 
the departmental Patient ID. 

Because of the need to perform reconciliation in multiple points throughout the enterprise, it is 
not recommended to use the workflow described in this note in the environment integrated in 
accordance with the IHE Technical Framework: Year 2. IHE Technical Framework in future 
years may define patient reconciliation transactions for this or similar cases using single point 
reconciliation with Master Patient Index (MPI). 

5.4.2 Use Cases 

The following sections describe the Unidentified Patient use cases. For the purpose of 
simplification, the following transaction were omitted from the corresponding diagrams: 

• Modality Performed Step In Progress 

• Modality Images Stored 

• Modality Presentation State Stored 

• Modality Storage Commitment 

These transactions may occur within the time frame of the diagram, but their content does not 
affect each of the use cases 

5.4.2.1 Case 1 : Unidentified Patient registered at ADT and ordered at Order Placer 

The ADT is a single point of patient reconciliation in the enterprise. Process flow requires that 
any unidentified patient be assigned a permanent Patient ID and a temporary name (e.g., “John 
Doe”). In this case, either the patient is registered/admitted electronically at the time of arrival, 
or is assigned a temporary Patient ID and name. All subsequent transactions follow the normal 
flow (see section 5.1) including order entry and procedure scheduling. When the real patient 
identity is known, the ADT is responsible for reconciliation of its own records as well as 
informing the Order Placer and DSS/Order Filler about corresponding changes. The ADT sends 
a Patient Update message to both the Order Placer and DSS/Order Filler. The DSS/Order Filler 
sends the Patient Update message to the Image Manager. 
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ADT 


Order 

Placer 


Department System Image 

Database/Scheduler/ Manager 

Order Filler 


Modality 



Figure 5.4-1. Unidentified Patient- Case 1 


Significant Transactions: 

• To reconcile the patient information, the ADT may register a new patient and merge the 
temporary patient with the correct patient and send both registration and merge 
transactions. 

• If a permanent Patient ID was assigned, then the ADT may only send a Patient Update 
transaction with proper information. 

.4.2.2 Case 2: Unidentified Patient registered at ADT and ordered at DSS/Order 
Filler 

This case is based on case 1. However, in this situation the order for a procedure is generated by 
the DSS/Order Filler and submitted to the Order Placer. Procedures are scheduled normally and 
image acquisition uses modality worklist. When the patient information is reconciled, the ADT 
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sends the Patient Update messages to both the Order Placer and DSS/Order Filler. The 
DSS/Order Filler sends the Patient Update message to the Image Manager. 


ADT 


Order 

Placer 


Department System Image 

Database/Scheduler/ Manager 

Order Filler 


Modality 



Figure 5.4-2. Unidentified Patient- Case 2 


Significant Transactions: 

• To reconcile the patient information, the ADT may register a new patient and merge the 
temporary patient with the correct patient and send both registration and merge 
transactions. 

• If a permanent Patient ID was assigned, then the ADT may only send a Patient Update 
transaction with proper information. 

• A New Order transaction is sent from DSS/Order Filler to the Order Placer. 
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.4.2.3 Case 3: Unidentified Patient registered at ADT but completed at Modality 
prior to Order 

As in cases 1 and 2, this uses a permanent Patient ID generated by the ADT. However, no order 
entry or scheduling takes place before the procedure is performed by the Acquisition Modality. 
A permanent Patient ID and a temporary name are manually entered at the Acquisition Modality 
(typically, from a card) and conveyed to the DSS/Order Filler and the Image Manager by the 
Acquisition Modality. Subsequently, the DSS/Order Filler generates and submits an order to the 
Order Placer. When the patient information is reconciled, the ADT sends the Patient Update 
messages to both the Order Placer and the DSS/Order Filler. The DSS/Order Filler sends a 
Patient Update message to the Image Manager. 
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Figure 5.4-3. Unidentified Patient- Case 3 


Significant Transactions: 

• On receiving a PPS message, the DSS/Order Filler recognizes it as an unscheduled case. 
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• The DS S/Order Filler sends a New Order transaction to the Order Placer. 

• Using the information from the Performed Procedure Step message and placed order, the 
DSS/Order Filler creates new Requested Procedure record and sends a Procedure 
Scheduled transaction to the Image Manager. 

• To reconcile the patient information, the ADT may register a new patient and merge the 
temporary patient with the correct patient and send both registration and merge 
transactions. 

• If a permanent Patient ID was assigned, then the ADT may only send a Patient Update 
transaction with proper information. 

• The DSS/Order Filler sends a Patient Update message to the Image Manager. 

.4.2.4 Case 4: Unidentified Patient assigned Temporary Departmental ID and 
Scheduled at DSS/Order Filler 

In this case, no valid Patient ID is available to the DSS/Order Filler. It assigns a temporary 
Patient ID and a temporary name and schedules the required procedure. 

Note: The DSS/Order Filler must ensure that the assigned temporary Patient ID is unique 
within its scope. 

The temporary Patient ID is conveyed to the Image Manager. When patient information 
becomes known, the ADT sends new patient information to both the Order Placer and the 
DSS/Order Filler. The DSS/Order Filler reconciles received patient information with that 
associated with the temporary Patient ID and merges the permanent patient record with its own 
temporary one and sends a Patient Update message to the Image Manager. At the same time, the 
DSS/Order Filler generates and submits an order to the Order Placer using a permanent Patient 
ID. 
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Figure 5.4-4. Unidentified Patient- Case 4 


Significant Transactions: 

• Patient information is reconciled internally by the DSS/Order Filler using the Patient 
Registration from ADT. 

• The DSS/Order Filler sends the Patient Ppdate to the Image Manager. 

• The DSS/Order Filler sends the New Order transaction to the Order Placer. 

.4.2.5 Case 5: Image Acquisition completed prior to assigning Temporary 
Departmental ID or Order 

In this case, no valid Patient ID is available to the DSS/Order Filler and no scheduling is done 
before the procedure is performed. A temporary ID and name are entered by the technologist at 
the Modality and conveyed to the DSS/Order Filler and to the Image Manager. The Patient ID 
and name are selected by the technologist according to the locally defined rules; for example, 
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selected from the predefined pool of “Patient ID - patient name” pairs. The rules for selecting 
temporary Patient ID shall guarantee its uniqueness within the scope of DSS/Order Filler. 

Upon receiving the Modality Procedure Step Completed message, the DSS/Order Filler and 
Image Manager recognize an unscheduled case based on the content of the message (see Note 
IHE-3 in appendix C). When patient information becomes known, the ADT sends the new 
patient information to both the Order Placer and DSS/Order Filler. The DSS/Order Filler 
performs a merge of the permanent patient record with the temporary one and sends a Patient 
Update to the Image Manager. At the same time, DSS/Order Filler generates and submits an 
order to the Order Placer using a valid Patient ID. 


ADT 


Order 

Placer 


Department System Image 

Database/Scheduler/ Manager 

Order Filler 


Modality 



Figure 5.4-5. Unidentified Patient - Case 5 

Significant Transactions: 

• On receiving a PPS message, the DSS/Order Filler recognizes it as an unscheduled case. 

• Patient information is reconciled internally by the DSS/Order Filler using the Patient 
Registration from the ADT. 

• The DSS/Order Filler sends a Patient Update message to the Image Manager. 

• The DSS/Order Filler sends a New Order transaction to the Order Placer. 
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• Using the information from the Performed Procedure Step message and placed order, the 
DS S/Order Filler creates new Requested Procedure record and sends a Procedure 
Scheduled Transaction to the Image Manager. 

.5 Virtual Image Set Split 

Virtual Image Set Split provides a mechanism for facilitating viewing images and reporting on 
individual Requested Procedures that have been fullfilled by a single Performed Procedure Step 
acquisition. The transactions covered are 5 through 10. 

The following use case illustrates the Virtual Image Set Split flow: 

• Two Requested Procedures (CT of the chest, and CT of the abdomen) are scheduled to 
fulfill an Order. A single Helical CT acquisition of the upper body is performed and a 
Modality Performed Procedure Step Completed transaction informing that both 
Requested Procedures have been grouped into one acquisition is sent to the Image 
Manager and Department System Scheduler/Order Filler (group case, see section 
6.6.4. 1.2. 3.4). Since two Requested Procedures have been satisfied, two reports may 
need to be created. The images are stored in the Image Archive and Storage 
Commitment is performed. 

• The technologist may create two Grayscale Softcopy Presentation States (GSPSs). One 
GSPS references the subset of images that correspond to the chest, and includes the 
viewing parameters (e.g. window/level settings) appropriate for the CT chest images. 

The other GSPS references the abdomen images subset, and includes different viewing 
parameters appropriate for the CT abdomen images. A Performed Procedure Step 
transaction indicating that the chest and abdomen GSPSs have been created is sent to the 
Image Manager and Department System Scheduler/Order Filler (append case, see section 
6. 6. 4. 1.2. 3. 3). The GSPSs are stored in the Image Archive and Storage Commitment is 
performed. 

• A radiologist may use the GSPSs created by the technologist to facilitate viewing and 
interpreting the CT chest images separately from the CT abdomen images. 

An implementation may choose to: 

• Include the results of Perform Acquisition and of Create GSPS in a single MPPS object; 

• Use two MPPS objects as described above and shown in figure 5.5-1; or 

• Use several MPPS objects, one for the results of Perform Acquisition, plus a separate 
MPPS object for each GSPS created (e.g. the results of CT Chest Create GSPS and CT 
Abdomen Create GSPS). 

The following sequence of steps describes the typical process flow involved in the Virtual Image 
Set Split: 


Rev. 4.0 
03-28-2000 


54 


Copyright © 2000: HIMSS/RSNA 



IHE Technical Framework: Year 2 


Department System 
Database/Scheduler/ 
Order Filler 


Image 

Manager 


Acquisition 

Modality 


Image 

Archive 



Figure 5.5-1. Virtual Image Set Split Process Flow 
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6 IHE Transactions 

This section defines each IHE transaction in detail, specifying the standards used, the 
information transferred, and the conditions under which the transaction is required or optional. 

6.1 Patient Registration 

This section corresponds to Transaction 1 of the IHE Technical Framework: Year 2. Transaction 
1 is required for the ADT, Order Placer and Department System Scheduler/Order Filler actors. 

6.1.1 Scope 

This process step involves the patient information, including demographics, captured at the point 
of encounter. This may occur when the visit is scheduled, if that precedes patient arrival at the 
institution. This transaction is used for both in-patients (i.e., those who are assigned a bed at the 
facility) and out-patients (i.e., those who are not assigned a bed at the facility) only when the new 
record is being created for a patient. 

6.1.2 Use Case Roles 



Actor: ADT 

Role: Adds and modifies patient demographic and encounter information. 

Actor: Order Placer 

Role: Receives patient and encounter information for use in order entry. 

Actor: Department System Database 

Role: Receives and stores patient and encounter information for use in fulfilling orders by the 
Department System Scheduler. 

Actor: MPI 

Role: Receives patient and encounter information from multiple ADT systems. Maintains unique 
enterprise- wide identifier for a patient. 

6.1.3 Referenced Standards 

HL7 2.3.1 Chapters 2, 3 
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6.1.4 Interaction Diagram 


ADT Patient Order Department System 

Registration Placer Database MPI 



Note: IHE Technical Frame work: Year 2 does not support the use of a Master Patient Index 
which is required for synchronization of patient information between multiple ADT systems 
employed by a healthcare enterprise. It is expected the IHE initiative will include an MPI Actor 
in the future and that the Patient Registration Transaction between the ADT and MPI will be 
similar to the transaction between the ADT and Order Placer and Order Filler actors. 

6.1. 4.1 Patient Management - Admit/Register Patient 

6.1. 4.1.1 Trigger Events 

The following events will trigger one of the Admit/Register messages: 

• A01 - Admission of an in-patient into a facility 

• A04 - Registration of an out-patient for a visit of the facility 

• A05 - Pre-admission of an in-patient (i.e., registration of patient information ahead of 
actual admission). 

6.1. 4.1. 2 Message Semantics 

The Patient Registration transaction is conducted by the HL7 ADT message. The message shall 
be generated by the ADT Actor whenever a patient is admitted, pre-admitted or registered. The 
segments of the message listed below are required, and their detailed descriptions are provided in 
tables 6.1-1 through 6.1-4 and corresponding notes. All other segments are optional. 

Note: Additional qualifications to the level of specification and HL7 profiling are stated in 
section 2.3. 


ADT 

Patient Administration 
Message 

Chapter in HL7 
2.3.1 

MSH 

Message Header 

2 

EVN 

Event Type 

3 

PID 

Patient Identification 

3 

PV1 

Patient Visit 
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ALl 


Allergy Information 3 


Each message shall be acknowledged by the HL7 ACK message sent by the receiver of ADT 
message to its sender. The segments of ACK message listed below are required, and their 
detailed descriptions are provided in tables 6.1-1, 6.1-6 and corresponding notes. All other 
segments are optional. 


ACK 

Acknowledgement 

Message 

Chapter in HL7 
2.3.1 

MSH 

Message Header 

2 

MSA 

Message Acknowledgement 

2 


The following tables provide field-by-field definitions of the required segments of the 
ADT/ACK messages of the Patient Registration transaction. These tables shall be interpreted 
according to the HL7 Standard unless otherwise noted in section 2.3 and notes beneath the 
tables. 


Table 6.1-1. IHE Profile - MSH segment 


SEQ 

LEN 

DT 

OPT 

TBL# 

ITEM# 

ELEMENT NAME 

1 

1 

ST 

R 


00001 

Field Separator 

2 

4 

ST 

R 


00002 

Encoding Characters 

3 

180 

HD 

R 


00003 

Sending Application 

4 

180 

HD 

R 


00004 

Sending Facility 

5 

180 

HD 

R 


00005 

Receiving Application 

6 

180 

HD 

R 


00006 

Receiving Facility 

7 

26 

TS 

O 


00007 

Date/Time Of Message 

8 

40 

ST 

O 


00008 

Security 

9 

7 

CM 

R 


00009 

Message Type 

10 

20 

ST 

R 


00010 

Message Control ID 

11 

3 

PT 

R 


00011 

Processing ID 

12 

8 

ID 

R 

0104 

00012 

Version ID 

13 

15 

NM 

O 


00013 

Sequence Number 

14 

180 

ST 

O 


00014 

Continuation Pointer 

15 

2 

ID 

O 

0155 

00015 

Accept Acknowledgment Type 

16 

2 

ID 

O 

0155 

00016 

Application Acknowledgment Type 

17 

2 

ID 

O 


00017 

Country Code 

18 

6 

ID 

C 

0211 

00692 

Character Set 

19 

60 

CE 

O 


00693 

Principal Language Of Message 


Adapted from the HL7 Standard, version 2.3.1 

The IHE Technical Framework requires that applications support HL7-recommended values for 
the fields MSH-1 Field Separator and MSH-2 Encoding Characters. 
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Field MSH-9 Message Type shall have at least two components. The first component shall have a 
value of “ADT” for ADT message and “ACK” for the ACK message; the second component 
shall have values of A01, A04 or A05 as appropriate. The third component is optional; however, 
if present, it shall have a value of ADT_01. 

Implementations supporting sequence number protocol shall be configurable to allow them to 
perform this transaction without such protocol. 


Table 6.1-2. IHE Profile - EVN segment 


SEQ 

LEN 

DT 

OPT 

TBL# 

ITEM# 

ELEMENT NAME 

1 

3 

ID 

O 

0003 

00099 

Event Type Code 

2 

26 

TS 

R 


00100 

Recorded Date/Time 

3 

26 

TS 

O 


00101 

Date/Time Planned Event 

4 

3 

IS 

O 

0062 

00102 

Event Reason Code 

5 

60 

XCN 

O 

0188 

00103 

Operator ID 

6 

26 

TS 

R2 


01278 

Event Occurred 


Adapted from the HL7 Standard, version 2.3.1 


Table 6.1-3. IHE Profile - PID segment 


SEQ 

LEN 

DT 

OPT 

TBL# 

ITEM# 

ELEMENT NAME 

1 

4 

SI 

O 


00104 

Set ID - Patient ID 

2 

20 

cx 

o 


00105 

Patient ID 

3 

20 

cx 

R 


00106 

Patient Identifier List 

4 

20 

cx 

O 


00107 

Alternate Patient ID 

5 

48 

XPN 

R 


00108 

Patient Name 

6 

48 

XPN 

O 


00109 

Mother’s Maiden Name 

7 

26 

TS 

R 


00110 

Date/Time of Birth 

8 

1 

IS 

R 

0001 

00111 

Sex 

9 

48 

XPN 

O 


00112 

Patient Alias 

10 

1 

IS 

R2 

0005 

00113 

Race 

11 

106 

XAD 

R2 


00114 

Patient Address 

12 

4 

IS 

O 


00115 

County Code 

13 

40 

XTN 

O 


00116 

Phone Number - Home 

14 

40 

XTN 

o 


00117 

Phone Number - Business 

15 

60 

CE 

o 

0296 

00118 

Primary Language 

16 

1 

IS 

0 

0002 

00119 

Marital Status 

17 

3 

IS 

o 

0006 

00120 

Religion 

18 

20 

CX 

R 


00121 

Patient Account Number 

19 

16 

ST 

O 


00122 

SSN Number - Patient 

20 

25 

DLN 

O 


00123 

Driver's License Number - Patient 

21 

20 

CX 

O 


00124 

Mother's Identifier 
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22 

3 

IS 

O 

0189 

00125 

Ethnic Group 

23 

60 

ST 

O 


00126 

Birth Place 

24 

2 

ID 

O 

0136 

00127 

Multiple Birth Indicator 

25 

2 

NM 

O 


00128 

Birth Order 

26 

4 

IS 

O 

0171 

00129 

Citizenship 

27 

60 

CE 

O 

0172 

00130 

Veterans Military Status 

28 

80 

CE 

O 


00739 

Nationality 

29 

26 

TS 

O 


00740 

Patient Death Date and Time 

30 

1 

ID 

O 

0136 

00741 

Patient Death Indicator 


Adapted from the HL7 standard, version 2.3.1 

Note: Every system participating in the information exchange using HL7 shall use the field 
PID-3 Patient Identifier List to convey the Patient ID uniquely identifying the patient, typically 
at the Master Patient Index. If the Master Patient Index is not available, the ID initially assigned 
by the ADT/Registration System may be conveyed in this field(IHE Technical Framework: Year 
2 does not provide for the use of an MPI). See appendix D and appendix G for further discussion 
of the use of PID-3 in transactions and its mapping from HL7 messages to DICOM Patient ID 
( 0010 , 0020 ). 


Table 6.1-4. IHE profile - PV1 Segment 


SEQ 

LEN 

DT 

OPT 

TBL# 

ITEM# 

ELEMENT NAME 

1 

4 

SI 

O 


00131 

Set ID-PV1 

2 

1 

IS 

R 

0004 

00132 

Patient Class 

3 

80 

PL 

R 


00133 

Assigned Patient Location 

4 

2 

IS 

O 

0007 

00134 

Admission Type 

5 

20 

CX 

O 


00135 

Preadmit Number 

6 

80 

PL 

O 


00136 

Prior Patient Location 

7 

60 

XCN 

R2 

0010 

00137 

Attending Doctor 

8 

60 

XCN 

R2 

0010 

00138 

Referring Doctor 

9 

60 

XCN 

R2 

0010 

00139 

Consulting Doctor 

10 

3 

IS 

O 

0069 

00140 

Hospital Service 

11 

80 

PL 

O 


00141 

Temporary Location 

12 

2 

IS 

O 

0087 

00142 

Preadmit Test Indicator 

13 

2 

IS 

O 

0092 

00143 

Readmission Indicator 

14 

3 

IS 

O 

0023 

00144 

Admit Source 

15 

2 

IS 

C 

0009 

00145 

Ambulatory Status 

16 

2 

IS 

O 

0099 

00146 

VIP Indicator 

17 

60 

XCN 

R2 

0010 

00147 

Admitting Doctor 

18 

2 

IS 

O 

0018 

00148 

Patient Type 

19 

20 

CX 

R2 


00149 

Visit Number 

20 

50 

FC 

O 

0064 

00150 

Financial Class 

21 

2 

IS 

O 

0032 

00151 

Charge Price Indicator 
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22 

2 

IS 

O 

0045 

00152 

Courtesy Code 

23 

2 

IS 

O 

0046 

00153 

Credit Rating 

24 

2 

IS 

O 

0044 

00154 

Contract Code 

25 

8 

DT 

O 


00155 

Contract Effective Date 

26 

12 

NM 

o 


00156 

Contract Amount 

27 

3 

NM 

o 


00157 

Contract Period 

28 

2 

IS 

o 

0073 

00158 

Interest Code 

29 

1 

IS 

o 

0110 

00159 

Transfer to Bad Debt Code 

30 

8 

DT 

o 


00160 

Transfer to Bad Debt Date 

31 

10 

IS 

o 

0021 

00161 

Bad Debt Agency Code 

32 

12 

NM 

o 


00162 

Bad Debt Transfer Amount 

33 

12 

NM 

o 


00163 

Bad Debt Recovery Amount 

34 

1 

IS 

o 

0111 

00164 

Delete Account Indicator 

35 

8 

DT 

0 


00165 

Delete Account Date 

36 

3 

IS 

o 

0112 

00166 

Discharge Disposition 

37 

25 

CM 

o 

0113 

00167 

Discharged to Location 

38 

2 

IS 

o 

0114 

00168 

Diet Type 

39 

2 

IS 

o 

0115 

00169 

Servicing Facility 

40 

1 

IS 

o 

0116 

00170 

Bed Status 

41 

2 

IS 

o 

0117 

00171 

Account Status 

42 

80 

PL 

o 


00172 

Pending Location 

43 

80 

PL 

o 


00173 

Prior Temporary Location 

44 

26 

TS 

o 


00174 

Admit Date/Time 

45 

26 

TS 

o 


00175 

Discharge Date/Time 

46 

12 

NM 

o 


00176 

Current Patient Balance 

47 

12 

NM 

o 


00177 

Total Charges 

48 

12 

NM 

o 


00178 

Total Adjustments 

49 

12 

NM 

o 


00179 

Total Payments 

50 

20 

CX 

o 

0192 

00180 

Alternate Visit ID 

51 

1 

IS 

o 

0326 

01226 

Visit Indicator 

52 

60 

XCN 

o 

0010 

01224 

Other Healthcare Provider 


Adapted from the HL7 standard, version 2.3.1 

Note: PID-18 (Patient Account Number) is required. PV1-19 (Visit Number) is required 
when PID-18 identifies an account which spans more than one Encounter or Visit. 


Table 6.1-5. IHE Profile - AL1 segment 


SEQ 

LEN 

DT 

OPT 

TBL# 

ITEM# 

ELEMENT NAME 

1 

4 

SI 

R 


00203 

Set ID - AL1 

2 

2 

IS 

O 

0127 

00204 

Allergy Type 

3 

60 

CE 

R 


00205 

Allergy 


61 

Rev. 4.0 Copyright © 2000: HIMSS/RSNA 

03-28-2000 





IHE Technical Framework: Year 2 








Code/Mnemonic/Description 

4 

2 

IS 

O 

0128 

00206 

Allergy Severity 

5 

15 

ST 

O 


00207 

Allergy Reaction 

6 

8 

DT 

O 


00208 

Identification Date 


Adapted from the HL7 standard, version 2.3.1 


Table 6.1-6. IHE Profile - MSA segment 


SEQ 

LEN 

DT 

OPT 

TBL# 

ITEM# 

ELEMENT NAME 

1 

2 

ID 

R 

0008 

00018 

Acknowledgment Code 

2 

20 

ST 

R 


00010 

Message Control ID 

3 

80 

ST 

O 


00020 

Text Message 

4 

15 

NM 

O 


00021 

Expected Sequence Number 

5 

1 

ID 

O 

0102 

00022 

Delayed Acknowledgment Type 

6 

100 

CE 

O 


00023 

Error Condition 


Adapted from the HL7 standard, version 2.3.1 


6.1. 4.1. 3 Expected Actions 

The receiver of the ADT Patient Registration transaction message shall create a new patient 
record for the patient identified if there is no current record for the Patient ID (defined by PID-2 
or, if it is empty, by PID-3). Interpretation of A01, A04 and A05 messages after the patient 
record was created is beyond the scope of the IHE Technical Framework; however, the ADT 
Patient Registration transaction shall not be used to update information in an existing patient 
record. Transaction 12 Patient Update shall be used instead. 

6.1. 4.2 Patient Management - Cancel Admit/Register Patient 

6.1. 4.2.1 Trigger Events 

The following events will trigger one of the Admit/Register messages: 

• All - Admission of an in-patient into a facility or registration of an out-patient for a visit 
of the facility has been cancelled due to error in the information or the decision not to 
admit/register patient after all. 

• A38 - Pre-admission of an in-patient (i.e., registration of patient information ahead of 
actual admission) has been cancelled due to error in the information or the decision not to 
admit/register patient after all. 

6.1. 4.2.2 Message Semantics 

Patient Registration conveyed by the HL7 ADT A A01, ADT A A04 or ADT A A05 may have to be 
revoked due to the errors in the information or the decision of not admitting/registering patient. 
The cancellation transaction is conveyed by the HL7 ADT A A11 or ADT A A38 messages. 
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ADT A A1 1 shall be used to revoke the transaction conveyed by the ADT A A01 or ADT A A04 
message. ADT A A38 shall be used to revoke transaction conveyed by the ADT A A05 message. 

Cancellation messages shall only be used if no other transactions were performed by the ADT on 
the patient record after the admit/registration transaction was conveyed. 

6.1. 4.2.3 Expected Actions 

If the patient record was created as a result of Patient Registration transaction, it shall be 
discarded. If the Patient Registration transaction was sent for an existing patient record, the 
corresponding operations shall be “rewound” to restore the record condition existing before 
Patient Transaction was sent. 

6.2 New Order 

This section corresponds to Transaction 2 of the IHE Technical Framework: Year 2. 

Transaction 2 is required for the Order Placer and Department System Scheduler/Order Filler 
actors. 

6.2.1 Scope 

This transaction is used by the Order Placer to place a new order with the Order Filler. It also 
allows the Order Filler to inform the Order placer about the new order the Order Filler had to 
create and fulfill. The Order Placer and Department System Scheduler/Order Filler must agree on 
the support of recurring orders and panel orders, if used. 

Recurring order: An order with a performance frequency greater than one. For example, portable 
chest x-ray at 6:00 AM for the next seven days. 

Panel order: A service item with more than one observation component. For example, a nuclear 
cardiac study, which has a cardiology component and a radiology component, which are usually 
reported on separately. 

6.2.2 Use Case Roles 



Actor: Order Placer 

Role: Places orders. Receives orders from order filler (department) system. 
Actor: Department System Scheduler/Order Filler 
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Role: Receives and processes (fills) orders. Creates new orders. Informs Order Placer of order 
status changes 

6.2.3 Referenced Standards 

HL7 2.3.1 Chapter 4, 7 

6.2.4 Interaction Diagram 

Order Created: 


Order Placer 


Department System 
Scheduler/Order Filler 



New Order from 
Order Placer 

New order from Dept 
Sys/Order Filler. 

New order ORM has 
control code of SN. 


Note: ORR messages are sent by the Order Placer to convey the Order Placer Number in those 
cases where the DS S/Order Filler places the Order. ORR messages are not used as 
acknowledgements in other cases. 

Order Status updated: 

Order Placer Department System 

Scheduler/Order Filler 


ORM (Status Change) 


Update Order Status 
from Dept Sys/Order 
Filler. 


6.2.4.1 Order Management - New Order from Order Placer 

6.2.4.1.1 Trigger Events 

ORM - The Order Placer places a new order for the Department System Scheduler/Order Filler. 
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6.2.4.1.2 Message Semantics 

HL7 2.3.1 Chapter 4 ORM message. Refer to HL7 Standard for general message semantics. See 
section 6.1 of this document for MSH, PID and PV1 segments. 

The order start date/time or exam date/time are required in the “Quantity/Timing” field of both 
the ORC and OBR segments (ORC-7.4; OBR-27.4). 

Note: Additional qualifications to the level of specification and HL7 profiling are stated in 
section 2.3. 

Required segments are listed below. Other segments are optional. 


ORM 

General Order 
Message 

Chapter in HL7 
2.3.1 

MSH 

Message Header 

2 

PID 

Patient Identification 

3 

PV1 

Patient Visit 

3 

{ORC 

Common Order 

4 

OBR 

Order Detail 

4 

{ [ OBX ] } } 

Observation Results 

7 


The OBX segment (observation results) is included to allow the transmission of the certain 
observation which may be required for proper handling of order, in particular, patient weight and 
height. A system that has patient weight and height information shall include corresponding 
OBX segments, among others. If this information is not known, sending system may still include 
OBX segments for other parameters. 


Table 6.2-1. IHE Profile - ORC Segment 


SEQ 

LEN 

DT 

OPT 

TBL# 

ITEM# 

ELEMENT NAME 

1 

2 

ID 

R 

0119 

00215 

Order Control 

2 

22 

El 

C 


00216 

Placer Order Number 

3 

22 

El 

R2 


00217 

Filler Order Number 

4 

22 

El 

C 


00218 

Placer Group Number 

5 

2 

ID 

C 

0038 

00219 

Order Status 

6 

1 

ID 

O 

0121 

00220 

Response Flag 

7 

200 

TQ 

R 


00221 

Quantity/Timing 

8 

200 

CM 

C 


00222 

Parent 

9 

26 

TS 

R 


00223 

Date/Time of Transaction 

10 

120 

XCN 

R2 


00224 

Entered By 

11 

120 

XCN 

O 


00225 

Verified By 

12 

120 

XCN 

R 


00226 

Ordering Provider 

13 

80 

PL 

O 


00227 

Enterer’s Location 


65 


Rev. 4.0 
03-28-2000 


Copyright © 2000: HIMSS/RSNA 




IHE Technical Framework: Year 2 


14 

40 

XTN 

R2 


00228 

Call Back Phone Number 

15 

26 

TS 

O 


00229 

Order Effective Date/Time 

16 

200 

CE 

O 


00230 

Order Control Code Reason 

17 

60 

CE 

R 


00231 

Entering Organization 

18 

60 

CE 

O 


00232 

Entering Device 

19 

120 

XCN 

O 


00233 

Action By 


Adapted from the HL7 Standard, version 2.3.1 

The action to be performed in the ORM message is defined by the Order Control code passed as 
part of the message. HL7 defines a number of Order Control codes. 

The order control codes below shall be supported. 


Table 6.2-2. IHE Profile - Supported Order Control Codes 


Value 

Description 

Originator 

nw r 

New order 

p 

"d 

> 

o 

Parent order 

F.P 

n 

X 

o 

Child order 

F,P 

SN r 

Send order number 

F 

na r 

Number assigned 

P 

sc R 

Status Changed 

F 


Adapted from the HL7 Standard, version 2.3.1 

P=Placer; F=Filler; R =Required; °=Optional 

Note: The use of Required/Optional superscripts in the Value column is an IHE extension and is 
not part of the HF7 Standard. 


Table 6.2-3. IHE Profile - OBR Segment 


SEQ 

LEN 

DT 

OPT 

TBL# 

ITEM# 

ELEMENT NAME 

1 

4 

SI 

C 


00237 

Set ID - OBR 

2 

75 

El 

c 


00216 

Placer Order Number 

3 

75 

El 

c 


00217 

Filler Order Number 

4 

200 

CE 

R 


00238 

Universal Service ID 

5 

2 

ID 

O 


00239 

Priority 

6 

26 

TS 

O 


00240 

Requested Date/time 

7 

26 

TS 

O 


00241 

Observation Date/Time 

8 

26 

TS 

O 


00242 

Observation End Date/Time 

9 

20 

CQ 

O 


00243 

Collection Volume 

10 

60 

XCN 

O 


00244 

Collector Identifier 

11 

1 

ID 

O 

0065 

00245 

Specimen Action Code 

12 

60 

CE 

R2 


00246 

Danger Code 

13 

300 

ST 

R2 


00247 

Relevant Clinical Info. 
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14 

26 

TS 

O 


00248 

Specimen Received Date/Time 

15 

300 

CM 

C 

0070 

00249 

Specimen Source 

16 

80 

XCN 

R 


00226 

Ordering Provider 

17 

40 

XTN 

O 


00250 

Order Callback Phone Number 

18 

60 

ST 

O 


00251 

Placer field 1 

19 

60 

ST 

O 


00252 

Placer field 2 

20 

60 

ST 

O 


00253 

Filler Field 1 

21 

60 

ST 

O 


00254 

Filler Field 2 

22 

26 

TS 

O 


00255 

Results Rpt/Status Chng - Date/Time 

23 

40 

CM 

O 


00256 

Charge to Practice 

24 

10 

ID 

O 

0074 

00257 

Diagnostic Serv Sect ID 

25 

1 

ID 

O 

0123 

00258 

Result Status 

26 

400 

CM 

O 


00259 

Parent Result 

27 

200 

TQ 

R 


00221 

Quantity /Timing 

28 

150 

XCN 

O 


00260 

Result Copies To 

29 

150 

CM 

C 


00261 

Parent 

30 

20 

ID 

R2 

0124 

00262 

Transportation Mode 

31 

300 

CE 

R2 


00263 

Reason for Study 

32 

200 

CM 

O 


00264 

Principal Result Interpreter 

33 

200 

CM 

O 


00265 

Assistant Result Interpreter 

34 

200 

CM 

O 


00266 

Technician 

35 

200 

CM 

O 


00267 

Transcriptionist 

36 

26 

TS 

O 


00268 

Scheduled Date/Time 

37 

4 

NM 

O 


01028 

Number of Sample Containers 

38 

60 

CE 

O 


01029 

Transport Logistics of Collected 
Sample 

39 

200 

CE 

O 


01030 

Collector’s Comment 

40 

60 

CE 

O 


01031 

Transport Arrangement 
Responsibility 

41 

30 

ID 

R2 

0224 

01032 

Transport Arranged 

42 

1 

ID 

O 

0225 

01033 

Escort Required 

43 

200 

CE 

O 


01034 

Planned Patient Transport Comment 


Adapted from the HL7 Standard, version 2.3.1 

Note: Specimen source holds the laterality (Left/Right) indicator (when used) in the <site 
modifier (CE)> component. See appendix D for details. 


Table 6.2-4. IHE Profile - OBX Segment 


SEQ 

LEN 

DT 

OPT 

TBL# 

ITEM# 

ELEMENT NAME 

1 

10 

SI 

o 


00569 

Set ID - OBX 

2 

2 

ID 

c 

0125 

00570 

Value Type 

3 

590 

CE 

R2 


00571 

Observation Identifier 
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4 

20 

ST 

C 


00572 

Observation Sub-ID 

5 

65536 1 

* 

C 


00573 

Observation Value 

6 

60 

CE 

o 


00574 

Units 

7 

10 

ST 

o 


00575 

References Range 

8 

5 

ID 

o 

0078 

00576 

Abnormal Flags 

9 

5 

NM 

o 


00577 

Probability 

10 

2 

ID 

o 

0080 

00578 

Nature of Abnormal Test 

11 

1 

ID 

o 

0085 

00579 

Observ Result Status 

12 

26 

TS 

o 


00580 

Date Last Obs Normal Values 

13 

20 

ST 

0 


00581 

User Defined Access Checks 

14 

26 

TS 

o 


00582 

Date/Time of the Observation 

15 

60 

CE 

o 


00583 

Producer's ID 

16 

80 

XCN 

o 


00584 

Responsible Observer 

17 

60 

CE 

o 


00936 

Observation Method 


Adapted from the HL7 Standard, version 2.3.1 

Note: The IHE Technical Framework includes the OBX segment primarily for the purposes of 
communicating patient height and weight. In this context, ITEM# 571 (Observation Identifier) 
has been changed to “R2” (OPT) and ITEM# 579 (Observation Result Status) has been changed 
to “O”. Please refer to appendix D for additional details on Patient Height and Weight mapping. 

The OPT value for 00574 Units is O. The IHE Technical Framework is using these OBX 
segments to send Patient Height and Weight. When the OBX segments are sent to transmit the 
height and weight, OBX. 6 (Units) should be populated. 

6.2.4.1.3 Expected Actions 

Department System Scheduler/Order Filler shall accept the order information for fulfillment. If 
error in data prevents it from fulfilling the order, it should notify the Order Placer by returning 
proper information in the ACK message. 

6.2.4.2 Order Management - New Order from Order Filler 
6.2.4.2.1 Trigger Events 

ORM - Department system Scheduler/Order Filler places an order (control code = SN). 

ORR - Order Placer replies (control code = NA). 


1 The length of the observation value field is variable, depending upon value type. See OBX-2-value type. 
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2. 4. 2. 2 Message Semantics 

HL7 2.3.1 Chapter 4 ORM message. Refer to HL7 Standard for general message semantics. 
Refer to section 6.2.4. 1.2 above for detailed requirements for the ORM message. 

HL7 2.3.1 Chapter 4 ORR message. Refer to HL7 Standard for general message semantics. 

See section 6.1 of this document for MSH and MSA segment definition. 

Note: Additional qualifications to the level of specification and HL7 profiling are stated in 
section 2.3. 

Required segments are listed below. Other segments are optional. 


ORR 

General Order 
Message 

Chapter in 
HL7 2.3.1 

MSH 

Message Header 

2 

MSA 

Message 

Acknowledgement 

2 

ORC 

Common Order 

4 

OBR 

Order Detail 

4 


Table 6.2-5. IHE Profile - ORC Segment 


SEQ 

LEN 

DT 

OPT 

TBL# 

ITEM# 

ELEMENT NAME 

1 

2 

ID 

R 

0119 

00215 

Order Control 

2 

22 

El 

R 


00216 

Placer Order Number 

3 

22 

El 

R 


00217 

Filler Order Number 

4 

22 

El 

C 


00218 

Placer Group Number 

5 

2 

ID 

R 

0038 

00219 

Order Status 

6 

1 

ID 

O 

0121 

00220 

Response Flag 

7 

200 

TQ 

C 


00221 

Quantity/Timing 

8 

200 

CM 

C 


00222 

Parent 

9 

26 

TS 

R 


00223 

Date/Time of Transaction 

10 

120 

XCN 

R2 


00224 

Entered By 

11 

120 

XCN 

O 


00225 

Verified By 

12 

120 

XCN 

R 


00226 

Ordering Provider 

13 

80 

PL 

O 


00227 

Enterer’s Location 

14 

40 

XTN 

R2 


00228 

Call Back Phone Number 

15 

26 

TS 

R 


00229 

Order Effective Date/Time 

16 

200 

CE 

O 


00230 

Order Control Code Reason 

17 

60 

CE 

R 


00231 

Entering Organization 

18 

60 

CE 

O 


00232 

Entering Device 

19 

120 

XCN 

O 


00233 

Action By 


Adapted from the HL7 Standard, version 2.3.1 
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The Order Control code passed as part of the message must have value NA - Number Assigned 
by the Order Placer. 


Table 6.2-6. IHE Profile - OBR Segment 


SEQ 

LEN 

DT 

OPT 

TBL# 

ITEM# 

ELEMENT NAME 

1 

4 

SI 

C 


00237 

Set ID - OBR 

2 

75 

El 

R 


00216 

Placer Order Number 

3 

75 

El 

R 


00217 

Filler Order Number 

4 

200 

CE 

R 


00238 

Universal Service ID 

5 

2 

ID 

R2 


00239 

Priority 

6 

26 

TS 

O 


00240 

Requested Date/time 

7 

26 

TS 

O 


00241 

Observation Date/Time 

8 

26 

TS 

O 


00242 

Observation End Date/Time 

9 

20 

CQ 

O 


00243 

Collection Volume 

10 

60 

XCN 

O 


00244 

Collector Identifier 

11 

1 

ID 

O 

0065 

00245 

Specimen Action Code 

12 

60 

CE 

R2 


00246 

Danger Code 

13 

300 

ST 

R2 


00247 

Relevant Clinical Info. 

14 

26 

TS 

O 


00248 

Specimen Received Date/Time 

15 

300 

CM 

C 

0070 

00249 

Specimen Source 

16 

80 

XCN 

R 


00226 

Ordering Provider 

17 

40 

XTN 

R2 


00250 

Order Callback Phone Number 

18 

60 

ST 

O 


00251 

Placer field 1 

19 

60 

ST 

O 


00252 

Placer field 2 

20 

60 

ST 

O 


00253 

Filler Field 1 

21 

60 

ST 

O 


00254 

Filler Field 2 

22 

26 

TS 

O 


00255 

Results Rpt/Status Chng - 
Date/Time 

23 

40 

CM 

O 


00256 

Charge to Practice 

24 

10 

ID 

R2 

0074 

00257 

Diagnostic Serv Sect ID 

25 

1 

ID 

O 

0123 

00258 

Result Status 

26 

400 

CM 

O 


00259 

Parent Result 

27 

200 

TQ 

R 


00221 

Quantity/Timing 

28 

150 

XCN 

O 


00260 

Result Copies To 

29 

150 

CM 

C 


00261 

Parent 

30 

20 

ID 

R2 

0124 

00262 

Transportation Mode 

31 

300 

CE 

R2 


00263 

Reason for Study 

32 

200 

CM 

O 


00264 

Principal Result Interpreter 

33 

200 

CM 

O 


00265 

Assistant Result Interpreter 

34 

200 

CM 

O 


00266 

Technician 

35 

200 

CM 

O 


00267 

Transcriptionist 
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36 

26 

TS 

O 


00268 

Scheduled Date/Time 

37 

4 

NM 

O 


01028 

Number of Sample Containers 

38 

60 

CE 

O 


01029 

Transport Logistics of Collected 
Sample 

39 

200 

CE 

O 


01030 

Collector’s Comment 

40 

60 

CE 

O 


01031 

Transport Arrangement 
Responsibility 

41 

30 

ID 

R2 

0224 

01032 

Transport Arranged 

42 

1 

ID 

O 

0225 

01033 

Escort Required 

43 

200 

CE 

O 


01034 

Planned Patient Transport 
Comment 


Adapted from the HL7 Standard, version 2.3.1 

Note: All required fields in the OBR segment, except OBR-2 Placer Order Number shall be 
copied by Order Placer from the ORM message received from the Order Filler. 

6.2.4.2.3 Expected Actions 

Order Placer shall accept and register order information transmitted from the Order Filler in the 
ORM message, assign its unique number to it and convey that number to order Filler in the ORR 
message. In turn, the Order Filler shall register received Order Placer number and include it into 
the subsequent communication of order status with Order Placer, as well as procedure-related 
information to the Image Manager and Acquisition Modality (see sections 6.4 and 6.5). 

6.2.4.3 Order Management - Order Status Update 

The Order Status Update Message is used by the DSS/Order Filler to notify Order Placer about 
changes in the status of the order as it is being fulfilled by the DSS/Order Filler. 

6.2.4.3.1 Trigger Events 

ORM - Department System Scheduler/Order Filler updates an order status (control code = SC). 

6.2.4.3.2 Message Semantics 

HF7 2.3.1 Chapter 4 ORM message. Refer to HF7 Standard for general message semantics. 

See section 6.1 of this document for MSH segment definition. 

Note: Additional qualifications to the level of specification and HF7 profiling are stated in 
section 2.. 

Required segments are listed below. Other segments are optional. 


ORR 

General Order 
Message 

Chapter in 
HL7 2.3.1 

MSH 

Message Header 

2 

ORC 

Common Order 

4 
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Table 6.2-7. IHE Profile - ORC Segment 


SEQ 

LEN 

DT 

OPT 

TBL# 

ITEM# 

ELEMENT NAME 

1 

2 

ID 

R 

0119 

00215 

Order Control 

2 

22 

El 

R 


00216 

Placer Order Number 

3 

22 

El 

R 


00217 

Filler Order Number 

4 

22 

El 

C 


00218 

Placer Group Number 

5 

2 

ID 

R 

0038 

00219 

Order Status 

6 

1 

ID 

O 

0121 

00220 

Response Flag 

7 

200 

TQ 

C 


00221 

Quantity/Timing 

8 

200 

CM 

C 


00222 

Parent 

9 

26 

TS 

R 


00223 

Date/Time of Transaction 

10 

120 

XCN 

O 


00224 

Entered By 

11 

120 

XCN 

O 


00225 

Verified By 

12 

120 

XCN 

O 


00226 

Ordering Provider 

13 

80 

PL 

O 


00227 

Enterer’s Location 

14 

40 

XTN 

02 


00228 

Call Back Phone Number 

15 

26 

TS 

O 


00229 

Order Effective Date/Time 

16 

200 

CE 

O 


00230 

Order Control Code Reason 

17 

60 

CE 

O 


00231 

Entering Organization 

18 

60 

CE 

O 


00232 

Entering Device 

19 

120 

XCN 

O 


00233 

Action By 


Adapted from the HL7 Standard, version 2.3.1 

When an Order Status Update (control code = SC) message is received at the Order Placer, the 
element ORC-5 “Order Status” will contain the reason for the status change. These reason shall 
be one of the following: 


Table 6.2-8. Order Status codes 


Value 

Description 

CM 

Order is completed 

CD 

Order was discontinued 

IP 

Order is in progress 


Adapted from the HL7 Standard, version 2.3.1 

2.4.3.3 Expected Actions 

DSS/Order Filler shall provide Order Placer with status updates on the order. At least the 
following events shall be noted: 

• In Progress - when the first Performed Procedure Step corresponding to the Order has 
been created; 
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• Completed - as defined by the Department System Scheduler; 

• Discontinued - if DSS/Order Filler discontinues the order after one or more 
corresponding Procedure Steps has been performed. 

6.3 Order Cancel 

This section corresponds to Transaction 3 of the IHE Technical Framework: Year 2. Transaction 
3 is required for the Order Placer and Department System Scheduler/Order Filler actors. 

6.3.1 Scope 

This transaction is used to cancel existing orders. Although the HF7 Standard supports a number 
of ways to change order information, IHE Technical Framework: Year 2 defines changing of 
orders by both Order Placer and Order Filler as a combination of Order Cancel followed by New 
Order. 

6.3.2 Use Case Roles 



Actor: Order Placer 

Role: Cancels orders or receives cancellation requests from the Department System 
Scheduler/Order Filler. 

Actor: Department System Scheduler/Order Filler 

Role: Cancels orders or or receives cancellation requests from the Order Placer. 

6.3.3 Referenced Standards 

HF7 2.3.1 Chapter 4, 7 
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6.3.4 Interaction Diagram 

Order Placer Department System 

Scheduler/Order Filler 




Cancel the Order from 
Dept Sys/Order Filler. 


Cancel the Order from 
Order Placer. 


6.3.4.1 Order Management - Order Cancelled by Order Placer 

6.3.4.1.1 Trigger Events 

ORM - Order Placer cancels an order (control code = CA). 

ORM - Order Placer discontinues an order which is currently in-progress (control code = DC). 

6.3.4.1.2 Message Semantics 

HL7 2.3.1 Chapter 4 ORM message. Refer to HL7 standard for general message semantics. 
Refer to section 6.2.4. 1.2 above for detailed requirements of the ORM message. 

Note: Additional qualifications to the level of specification and HL7 profiling are stated in 
section 2.3. 

The action to be performed in the ORM message is defined by the Order Control code passed as 
part of the message. The order control codes below shall be supported. 


Table 6.3-1. IHE Profile - Supported Order Control Codes 


Value 

Description 

Originator 

CA 

Cancel order request 

p 

DC 

Discontinue Order request 

p 


6.3.4.1.3 Expected Actions 

After receiving the ORM message with the control code CA, DSS/Order Filler shall discard the 
record of the order and should not attempt to schedule or otherwise to fulfill it. If the DSS/Order 
Filler has already scheduled the procedures corresponding to the order, it has to perform 
Transaction 13 Procedure Update (see section 6.13) to notify the Image Manager of order 
cancellation. 
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After receiving the ORM message with the control code DC, DSS/Order Filler shall perform 
Transaction 13 Procedure Update (see section 6.13) to notify the Image Manager of order 
discontinuation. 

6.3.4.2 Order Management - Order Cancelled by Department System 
Scheduler/Order Filler 

6.3.4.2.1 Trigger Events 

ORM - Department System Scheduler/Order Filler cancels the order previously received from 
Order Placer (control code = OC). 

6. 3. 4. 2. 2 Message Semantics 

HF7 2.3.1 Chapter 4 ORM message. Refer to HF7 standard for general message semantics. 
Refer to section 6.2.4. 1.2 above for detailed requirements of the ORM message. 

Note: Additional qualifications to the level of specification and HF7 profiling are stated in 
section 2.3. 

The action to be performed in the ORM message is defined by the Order Control code passed as 
part of the message. The order control code below shall be supported. 


Table 6.3-2. IHE Profile - Supported Order Control Codes 


Value 

Description 

Originator 

OC 

Order Cancelled 

F 


6.3.4.2.3 Expected Actions 

After receiving the ORM message with the control code OC, Order Placer shall process the order 
the same way as if it was cancelled/discontinued by the Order Placer. 

If DSS/Order Filler has already scheduled the procedures corresponding to the order, it has to 
perform Transaction 13 Procedure Update (see section 6.13) to notify the Image Manager of 
order cancellation. 

6.4 Procedure Scheduled 

This section corresponds to Transaction 4 of the IHE Technical Framework: Year 2. Transaction 
4 is required for the Department System Scheduler/Order Filler and Image Manager actors. 

6.4.1 Scope 

This transaction specifies a message from the Department System Scheduler/Order Filler to the 
Image Manager identifying that a procedure has been scheduled. 

Scheduling does not necessarily mean precise time assignment for the particular procedures. For 
example, inpatient procedures are not necessarily scheduled for a specific time slot, but rather for 
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“today” or “as soon as possible”. However, the Department System Scheduler/Order Filler shall 
handle all orders in such a way that it is capable of informing the Image Manager about 
procedure timing and resources used to perform a procedure. It must provide the date and time 
when the procedure is to be performed, although precision of the time portion of that information 
is allowed to be implementation-dependent. 

This message serves as a trigger event for the Image Manager, informing it to obtain necessary 
information and apply rules to ensure the availability of relevant information to the end user. The 
Image Manager may need the information to create the Requested Procedure context for its 
purposes. The Procedure Scheduled transaction includes the initial scheduling message.The 
Procedure Scheduled message is also used to provide additional information from the 
Department System Scheduler to the Image Manager for unscheduled cases. In the event that a 
procedure is performed prior to ordering (as in some of the use cases in section 5.4), this 
message is used “after the fact” for the Department System Schedule to inform the Image 
Manager of critical information such as Accession Number and Requested Procedure ID. This is 
described in more detail within this section. 

The Department System Scheduler/Order Filler will need to communicate with multiple Image 
Managers. The Department System Scheduler/Order Filler shall broadcast these scheduling 
messages to all Image Managers. An Image Manager shall be able to receive and process these 
messages with the understanding that the images and MPPS events for these procedures may be 
sent to a different Image Manager. 

.4.2 Use Case Roles 



Actor: Department System Scheduler/Order Filler 

Role: Enters, modifies and stores information about patients, receives orders, schedules 
Procedures (exams), modifies information about them (rescheduling, cancellations, code 
changes, etc.). 
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Actor: Image Manager 

Role: Receives information about Patients, Orders, and schedules, and uses this information to 
assist in image management. 

6.4.3 Referenced Standards 

HL7 2.3.1 Chapter 2-4 

6.4.4 Interaction Diagram 

Departmental System Image Manager 

Scheduler/Order Filler 

I 

I I 

I I 

I | 

I | 



6.4.4.1 Procedure Scheduled Message 

6.4.4.1.1 Trigger Events 

The Department System Scheduler/Order Filler determines procedures which need to be 
performed to fill the order, what Procedure Steps need to be performed for each Procedure, and 
timing and necessary resources. 

Note: This transaction should be used when it is the first time that a particular Study Instance 
UID is being sent from the Department System Scheduler/Order Filler to the Image Manager. If 
this is not the first usage of a particular Study Instance UID, then Procedure Updated 
(Transaction 13) should be used. 

6.4.4.1.2 Message Semantics 

The Department System Scheduler/Order Filler uses an ORM message to convey necessary 
procedure and scheduling information. 

The Procedure Scheduled Transaction will perform the additional task of providing Patient 
Demographic information to the Image Manager. The Image Manager does not receive all 
Patient Registration events from the ADT System because it is not necessary for the Image 
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Manager to be aware of all patients in the enterprise (since most will never have an imaging 
procedure). The Image Manager shall obtain the Patient Demographic information from the 
Procedure Schedule ORM, specifically the PID and PV1 segments. For this reason, the 
Department System Scheduler/Order Filler must complete these segments as described in section 
6.1, Patient Registration. 

Note: Additional information regarding HF7 conventions, profiling, and implementation 
considerations are given in section 2.3. 

.4.4.1. 2.1 ORM Message structure 

The segments listed below are required. All other segments are optional. 


ORM 

General Order Message 

Chapter in HL7 2.3 

MSH 

Message Header 

2 

PID 

Patient Identification 

3 

PV1 

Patient Visit 

3 

{ORC 

Common Order 

4 

OBR( 

Order Detail 

4 

ZDS 

Additional identification information 
(custom for IHE) 



MSH, PID and PV1 Segments are described earlier in section 6.1. The Required and Optional 
fields described in the Patient Registration Transaction 1 are applicable to the PID and PV 1 
segments of this transaction. 

MSH-9 shall contain the value “ORM”. 


Table 6.4-1. IHE Profile - ORC Segment 


SEQ 

LEN 

DT 

OPT 

TBL# 

ITEM# 

ELEMENT NAME 

1 

2 

ID 

R 

0119 

00215 

Order Control 

2 

22 

El 

R 


00216 

Placer Order Number 

3 

22 

El 

R 


00217 

Filler Order Number 

4 

22 

El 

O 


00218 

Placer Group Number 

5 

2 

ID 

R 

0038 

00219 

Order Status 

6 

1 

ID 

O 

0121 

00220 

Response Flag 

7 

200 

TQ 

R 


00221 

Quantity/Timing 

8 

200 

CM 

O 


00222 

Parent 

9 

26 

TS 

O 


00223 

Date/Time of Transaction 

10 

120 

XCN 

R2 


00224 

Entered By 

11 

120 

XCN 

O 


00225 

Verified By 

12 

120 

XCN 

R2 


00226 

Ordering Provider 

13 

80 

PL 

R2 


00227 

Enterer" s Location 
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14 

40 

XTN 

R2 


00228 

Call Back Phone Number 

15 

26 

TS 

O 


00229 

Order Effective Date/Time 

16 

200 

CE 

O 


00230 

Order Control Code Reason 

17 

60 

CE 

R2 


00231 

Entering Organization 

18 

60 

CE 

O 


00232 

Entering Device 

19 

120 

XCN 

O 


00233 

Action By 


Adapted from the HL7 Standard, version 2.3.1 

The Department System Scheduler uses the ORM message in a context that is different from the 
context existing between Order Placer and Order Filler. The Department System 
Scheduler/Order Filler shall send as many ORM messages as there are Requested Procedures 
identified to fill a single order. Each ORM message shall contain as many ORC/OBR pairs as 
there are Action Items in all Scheduled Procedure Steps for that Requested Procedure. 

It is actually common for the Department System Scheduler/Order Filler to receive a single 
ORM from the Order Placer system, but choose to expand that order into multiple Requested 
Procedures, therefore sending multiple ORMs to the Image Manager. Taking this into account, 
the Department System Scheduler will consider itself an “order placer” in relation to the Image 
Manager. 

Required fields in the ORC segment shall be filled by the Department System Scheduler as given 
in the following table. 


Table 6.4-2. DSS Mappings of the ORC Segment 


Element Name 

Seq 

Element Shall Contain: 

Notes 

Order Control Code 

ORC-l 

“NW" 

New order 

Placer Order Number 

ORC-2 

Placer Order Number received 
from Order Placer 

In the event that the Order Filler 
places the order, the Order Filler 
shall not send the scheduling 
ORM message until it has 
received the Placer Order 
Number from the Order Placer 
(through an ORR message). 

Filler Order Number 

ORC-3 

Filler Order Number 

Number generated internally by 
the Department System 
Scheduler 

Order Status 

ORC-5 

“SC” 

Scheduled 

Quantity/Timing 

ORC-7 

Date and time of the Scheduled 
Procedure Step (in the fourth 
component) 



Additional information is transmitted in the OBR segment. Per the HF7 Standard, IHE 
recommends that the fields in ORC and OBR segments given in the following table contain 
the same information (See table 6.4-3). 
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Table 6.4-3. Identical Element Mappings between ORC and OBR Segments 


Element Name 

ORC Segment Element 

OBR Segment Element 

Placer Order Number 

ORC-2 

OBR-2 

Filler Order Number 

ORC-3 

OBR-3 

Quantity/Timing 

ORC-7 

OBR-27 


The HL7 OBR segment used for this message is described in table 6.4-4. 


Table 6.4-4. IHE Profile - OBR Segment 


SEQ 

LEN 

DT 

OPT 

TBL# 

ITEM# 

ELEMENT NAME 

1 

4 

SI 

R 


00237 

Set ID - OBR 

2 

75 

El 

R 


00216 

Placer Order Number 

3 

75 

El 

R 


00217 

Filler Order Number 

4 

200 

CE 

R 


00238 

Universal Service ID 

5 

2 

ID 

R2 


00239 

Priority 

6 

26 

TS 

O 


00240 

Requested Date/time 

7 

26 

TS 

O 


00241 

Observation Date/Time 

8 

26 

TS 

O 


00242 

Observation End Date/Time 

9 

20 

CQ 

O 


00243 

Collection Volume 

10 

60 

XCN 

O 


00244 

Collector Identifier 

11 

1 

ID 

O 

0065 

00245 

Specimen Action Code 

12 

60 

CE 

R2 


00246 

Danger Code 

13 

300 

ST 

R2 


00247 

Relevant Clinical Info. 

14 

26 

TS 

O 


00248 

Specimen Received Date/Time 

15 

300 

CM 

C 

0070 

00249 

Specimen Source 

16 

80 

XCN 

R2 


00226 

Ordering Provider 

17 

40 

XTN 

R2 


00250 

Order Callback Phone Number 

18 

60 

ST 

R 


00251 

Placer field 1 

19 

60 

ST 

R 


00252 

Placer field 2 

20 

60 

ST 

R 


00253 

Filler Field 1 

21 

60 

ST 

O 


00254 

Filler Field 2 

22 

26 

TS 

O 


00255 

Results Rpt/Status Chng - Date/Time 

23 

40 

CM 

O 


00256 

Charge to Practice 

24 

10 

ID 

R 

0074 

00257 

Diagnostic Serv Sect ID 

25 

1 

ID 

O 

0123 

00258 

Result Status 

26 

400 

CM 

O 


00259 

Parent Result 

27 

200 

TQ 

R 


00221 

Quantity/Timing 

28 

150 

XCN 

O 


00260 

Result Copies To 

29 

150 

CM 

O 


00261 

Parent 

30 

20 

ID 

R2 

0124 

00262 

Transportation Mode 
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31 

300 

CE 

R2 


00263 

Reason for Study 

32 

200 

CM 

O 


00264 

Principal Result Interpreter 

33 

200 

CM 

O 


00265 

Assistant Result Interpreter 

34 

200 

CM 

O 


00266 

Technician 

35 

200 

CM 

O 


00267 

Transcriptionist 

36 

26 

TS 

O 


00268 

Scheduled Date/Time 

37 

4 

NM 

O 


01028 

Number of Sample Containers 

38 

60 

CE 

O 


01029 

Transport Logistics of Collected Sample 

39 

200 

CE 

O 


01030 

Collector’ s Comment 

40 

60 

CE 

O 


01031 

Transport Arrangement Responsibility 

41 

30 

ID 

O 

0224 

01032 

Transport Arranged 

42 

1 

ID 

O 

0225 

01033 

Escort Required 

43 

200 

CE 

O 


01034 

Planned Patient Transport Comment 


Adapted from the HL7 Standard, version 2.3.1 

Other required fields in the OBR segment shall be filled by the Department System Scheduler as 
defined in the following table. 


Table 6.4-5: DSS mappings of the OBR Segment 


Element Name 

Seq 

Shall Contain: 

Notes 

Placer Field 2 

OBR-19 

Requested Procedure ID 

All OBR segments within a single ORM 
message shall have the same value in this 
field. " 

Filler Field 1 

OBR-20 

Scheduled Procedure Step ID 

If a Scheduled Procedure Step has 
multiple Action Items, several ORC 
segments within a single ORM message 
may have the same value in this field. 

Placer Field 1 

OBR- 18 

Accession Number 


Universal Service ID 

OBR-4 

Both the Requested Procedure 
Description /Code and the 
Scheduled Procedure Step 
Description/ Action Item Code. 

Components 1-3 of OBR-4 shall be 
copied by the Order Filler from the 
components 1-3 of OBR-4 it obtains 
from the ORM message (OBR segment) 
conveyed to it by the Order Placer. 
Components 4-6 shall be filled with the 
Scheduled Procedure Step 
Description/ Action Item Code. 
Components 1-3 of OBR-4 field shall 
have the same value within one ORM 
message. 

Specimen Source 

OBR- 15 

The fifth component.Site Modifier, 
shall be used for the L/R indicator. 
The L/R value shall be appended to 
the Requested Procedure 
Description (0032,1060). 

This element shall only be used if the 
coding scheme which is employed does 
not contain laterality within the coding 
scheme itself. If laterality is inherent in 
the coding scheme, this element shall not 
be sent. 

Diagnostic Service 
Section ID 

OBR-24 

DICOM Modality 

The Modality attribute of DICOM 
consists of Defined Terms which should 
be used in this element. 
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A custom ZDS Segment is defined to convey information generated by the Order Filler and not 
currently defined in the HF7 standard and is given in the following table. 


Table 6.4-6. IHE Profile - ZDS Segment 


SEQ 

LEN 

DT 

OPT 

TBL# 

ITEM# 

ELEMENT NAME 

1 

200 

RP 

R 


Z0001 

Study Instance UID 


Components of the Study Instance UID field shall be encoded as given in the table 6.4-7. 


Table 6.4-7. Z Segment Study Instance UID Element Components 


Component Number 

Component Name 

Shall Contain: 

l 

Reference Pointer 

DICOM compliant Study Instance UID value 

2 

Application ID 

Implementation specific 

3 

Type of Data 

“Application” 

4 

Subtype 

“DICOM” 


6.4.4.2 Expected Actions 
6.4.4.2.1 Use Cases 

The intent of this section is to illustrate, using use cases, how key information is used in a 
Procedure Scheduled transaction. 

See section 5.1 (Typical Process Flow) for illustrations of the following discussions: 

• Section 5. 1.2.1: In the case where the patient demographics are updated or patients are 
merged prior to placer order creation, this transaction occurs normally using the updated 
patient and visit information. 

• Section 5. 1.2. 2: In the case where the patient demographics are updated or patients are 
merged after a procedure has been scheduled, only a Patient Update transaction is 
required, and this transaction is not affected. 

• Section 5.1.3: In the case where an order is cancelled at the Order Placer or Order Filler 
and a new order is generated, the previously scheduled order (ORM) sent to the Image 
Manager should be cancelled (see section 6.13) and a new Procedure Scheduled 
transaction should be initiated for the “new” order. 

See section 5.4 (Unidentified Patient Image Acquisition) for illustrations of the following 
discussions: 

• Case 1: In the case where a Temporary Patient Name and ID are assigned by an ADT 
system and an order is placed at the Order Placer, a Procedure Update transaction is not 
necessary (only a Patient Update transaction is necessary). 


82 


Rev. 4.0 Copyright © 2000: HIMSS/RSNA 

03-28-2000 





IHE Technical Framework: Year 2 


• Case 2: In the case where a Temporary Patient Name and ID are assigned by an ADT 
system but the order is placed at the Department System Scheduler, a Procedure Update 
transaction is not necessary (only a Patient Update transaction is necessary). 

In both cases 1 and 2, the DICOM attribute information mapping given in the Procedure 
Scheduled Transaction remains the same. That is, the Study Instance UID, Requested Procedure 
ID, Accession Number, etc., are supplied by the Department System Scheduler, are used by the 
modality and Image Manager, and are not changed. 

• Case 3: In this case a Temporary Patient Name and ID are assigned by an ADT system, 
no order is placed prior to image acquisition, but rather an order is placed after the exam 
is completed, the Study Instance UID is generated by the acquisition modality, and a 
Modality Performed Procedure Step is sent to the Image Manager and Department 
System Scheduler (containing the modality generated Study Instance UID). As always, 
the Study Instance UID contained within an object set remains the “master” key. 

At this point, a Procedure Scheduled transaction (Control Code = NW) must be sent to 
the Image Manager using the Study Instance UID contained in the MPPS message from 
the acquisition device. In this case, the information given in table 6.4-8 must be altered 
by the Image Manager using the information received in the Procedure Update ORM by 
changing the DICOM objects. 

Table 6.4-8. Data Mapping from ORM by Image Manager after Procedure Scheduled 

Attributes Overwritten in DICOM Instances 
Based on Procedure Scheduled 
information 

Placer Order Number + Issuer 
Filler Order Number + Issuer 
Accession Number 
Requested Procedure ID 


It should be noted that in case 3, the reconciliation of Scheduled Procedure Steps which are 
identified by the Department System Scheduler and contained in the Procedure Scheduled 
message with the Performed Procedure Steps that are actually contained in the DICOM objects 
(MPPS object) may not be consistent and do not need to be coerced At this point, the number 
and identification of the Scheduled Procedure Steps is irrelevant because the procedure has 
already been performed. 

If a race condition should occur such that the Department System Scheduler has just created a 
Procedure Scheduled Transaction (and generated a Study Instance UID) and the Modality has 
generated DICOM objects (and generated a different Study Instance UID) it is the responsibility 
of the Department System Scheduler to reconcile these transactions by canceling the order (and 
Study Instance UID) that it generated internally and create a new Procedure Scheduled 
transaction using the Study Instance UID generated by the modality and provided in the 
Modality Performed Procedure Step transaction. If it is a multimodality study with multiple 
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Study Instance UIDs then multiple Procedure Scheduled transactions must be generated by the 
Department System Scheduler. The studies may still be reported as one Requested Procedure 
(see sections 6.24-6.27). 

In case 3, a Patient Update Transaction(s) must still be sent to the Image Manager to update the 
patient demographic, visit information, and ID. 

• Case 4: In the case where a Department Temporary Patient Name and ID are assigned by 
the Departmental System Scheduler and the procedure is scheduled, a Procedure 
Scheduled transaction is necessary and adequately provides the Study Instance UID and 
other information given in table 6.4-8. Subsequently, a Patient Update transaction(s) is 
necessary. 

• Case 5: In the case where no Temporary Patient Name nor ID are assigned by an ADT 
system, no order is placed in advance, but rather the patient is registered at the 
Department System Scheduler and the order is placed after the exam is complete a 
Procedure Scheduled transaction (Control Code = NW) must be sent to the Image 
Manager. Similar to case 3, the Study Instance UID obtained in the Modality Performed 
Procedure Step message should be used as the key by both the Department System 
Scheduler and the Image Manager. The information given in table 6.4-8 must be altered 
by the Image Manager using the information received in the Procedure Scheduled ORM. 

In case 5, a Patient Update Transaction(s) must still be sent to the Image Manager to 
update the patient demographic, visit information and ID. 

6.5 Modality Worklist Provided 

This section corresponds to Transaction 5 of the IHE Technical Framework: Year 2. 

Transaction 5 is required for the Department System Scheduler/Order Filler Actor and the 
Acquisition Modality Actor. 

6.5.1 Scope 

This transaction takes place at the Acquisition Modality at the point of scan/acquisition by a 
technologist. When a patient arrives for the scheduled procedure, the technologist performing the 
procedure must examine key information elements as they relate to the procedure, the 
correctness of the procedure that has been ordered, and comments that may have been entered by 
the referring physician and/or radiologist, among others. The technologist at the Acquisition 
Modality uses the DICOM Modality Worklist to query the Department System Scheduler/Order 
Filler for Scheduled Procedure Steps. The list is downloaded to the Acquisition Modality and the 
technologist verifies the information on the Acquisition Modality console. In the Modality 
Images Stored transaction this information will be included in the header of the generated images 
(See section 6.8 and appendix C). 


84 


Rev. 4.0 Copyright © 2000: HIMSS/RSNA 

03-28-2000 



IHE Technical Framework: Year 2 


6.5.2 Use Case Roles 



Actor: Acquisition Modality 

Role: Responsible for requesting and receiving data from the Department System 
Scheduler/Order Filler, with the ability to validate the data and correct some discrepancies. 

Actor: Department System Scheduler/Order Filler 

Role: Responsible for accepting requests for MWF from an acquisition modality, performing 
the query, and sending the response back. 

6.5.3 Referenced Standards 

DICOM 1999 PS 3.4: Modality Worklist SOP Class 

6.5.4 Interaction Diagram 

Acquisition Department System 

Modality Scheduler/Order Filler 



6.5.4.1 Query Scheduled MWL Message 

This is the worklist query message sent to the Department System Scheduler/Order Filler. 

6.5.4.1.1 Trigger Events 

The patient arrives at the Acquisition Modality for a procedure. 
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6.5.4.1.2 Message Semantics 

The Acquisition Modality uses the C-FIND Request of the DICOM Modality Worklist SOP 
Class to query for the worklist from the DSS/Order Filler. The Acquisition Modality performs 
the SCU role, and the DSS/Order Filler the SCP role. 

At least one of the following cases shall be implemented by the Acquisition Modality: 

1. The Patient Based Query: Query for a worklist specific for a particular patient. The SCU 
shall support all (15) combinations of the matching key attributes listed in table 6.5-1 by 
including 1 or more keys. 


Table 6.5-1. MWL Keys for Query by Patient 


Matching Key Attributes 

Tag 

Patient's Name 

(0010,0010) 

Patient ID 

(0010,0020) 

Accession Number 

(0008,0050) 

Requested Procedure ID 

(0040,1001) 


2. The Broad Query: Query for a broad worklist. The SCU shall support all (7) combinations 
of the matching key attributes listed in table 6.5-2 by including 1 or more keys. 

Table 6.5-2. MWL Keys for Broad Worklist Queries 


Matching Key Attributes 

Tag 

Scheduled Procedure Step Start Date 

(0040,0002) 

Modality 

(0008,0060) 

Scheduled Station AE-Title 

(0040,0001) 


6.5.4.1.2.1 Examples for the Use of Matching Key Attributes 

• Using the Scheduled Procedure Step Start Date: query for all the procedures in my 
department that are scheduled for the start date specified. 

• Using the Modality key: query for all the procedures that are scheduled on this type of 
modality (e.g., all CT exams). 

• Using AE Title key: query for all the procedures that are scheduled on the modality with 
the specified AE Title. 

• Using the Scheduled Procedure Step Start Date and Modality keys: query for all the CT 
procedures that are scheduled for today. 

Note: DICOM defines that dates and times are matched by their meaning, not as literal strings. If 
an application is concerned about how a single value matching of dates and times is performed 
by another application, it may consider using range matching instead (e.g. "<today>-<today>"), 
which is always performed by meaning. 
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Note: Applications are recommended to append a wildcard at the end of each component of 
the structured Patient Name to facilitate matching with both structured and unstructured Patient 
Names. 

6.5.4.1.2.2 Matching Keys and Return Keys for Display 

The Modality is required to query for specific attributes (return keys) that will be inserted into 
the image objects. The requirements for the attributes in the stored images are defined in section 
6.8 and appendix C. There are additional attributes which may be queried for use on the 
Acquisition Modality but might not be inserted into the composite image object. 

Table 6.5-3 summarizes the matching key requirements and lists the optional and required 
attributes that may be requested and should be returned in order to make these available to the 
user at the Acquisition Modality. See section 2.2 for more information on the requirements 
expressed in this table. All display requirements are an addition to the DICOM Standard 
requirements for the Modality Worklist SOP Class. 


Table 6.5-3. Return and Matching Keys For Modality Worklist 


Attribute Name 

Tag 

Query Keys Matching 

Query Keys Return 

SCU 

SCP 

SCU 

SCP 

Scheduled Procedure Step 

Scheduled Procedure Step 
Sequence 

(0040,0100) 

R+ 

R 

R+* 

R 

>Scheduled Station AE Title 

(0040,0001) 

R+ 

R 

R+* 

R 

>Scheduled Procedure Step 
Start Date 

(0040,0002) 

R+ 

R 

R+ 

R 

>Scheduled Procedure Step 
Start Time 

(0040,0003) 

O 

R 

R+ 

R 

> Scheduled Procedure Step 
Location 

(0040,0011) 

O 

O 

O 

O 

>Modality 

(0008,0060) 

R+ 

R 

R+ 

R 

>Scheduled Performing 
Physician's Name 

(0040,0006) 

O 

O 

O 

R 

>Scheduled Procedure Step ID 

(0040,0009) 

O 

O 

R+* 

R 

>Scheduled Action Item Code 
Sequence 

(0040,0008) 

O 

O 

R+* 

R 

»Code Value 

(0008,0100) 

O 

O 

R+* 

R 

»Coding Scheme Version 

(0008,0103) 

O 

O 

O 

O 

»Coding Scheme Designator 

(0080,0102) 

O 

O 

R+* 

R 

»Code Meaning 

(0080,0104) 

O 

O 

R+* 

R+ 

>Scheduled Procedure Step 
Description 

(0040,0007) 

O 

O 

R+ 

R 

Requested Procedure 

Requested Procedure Comments 

(0040,1400) 

o 

O 

O 

O 

Requested Procedure 

(0032,1060) 

0 

O 

R+ 

R 
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Description 






Requested Procedure Code 
Sequence 

(0032,1064) 

o 

O 

R+* 

R 

>Code Value 

(0008,0100) 

o 

o 

R+* 

R 

>Coding Scheme Version 

(0008,0103) 

o 

o 

O 

O 

>Coding Scheme Designator 

(0008,0102) 

0 

0 

R+* 

R 

>Code Meaning 

(0008,0104) 

0 

0 

R+* 

R+ 

Requested Procedure ID 

(0040,1001) 

R+ 

R+ 

R+ 

R 

Names of Intended recipients of 
results 

(0040,1010) 

O 

O 

O 

O 

Study Instance UID 

(0020.000D) 

O 

O 

R+* 

R 

Referenced Study Sequence 

(0008,1110) 

O 

O 

R+* 

R 

>Referenced SOP Class UID 

(0008,1150) 

O 

0 

R+* 

R 

>Referenced SOP Instance UID 

(0008,1155) 

o 

0 

R+ 

R 

Imaging Service Request 

Imaging Service Request 
Comments 

(0040,2400) 

o 

o 

O 

O 

Accession Number 

(0008,0050) 

R+ 

R+ 

R+ 

R+ 

Requesting Physician 

(0032,1032) 

O 

O 

O 

R 

Requesting Service 

(0032,1033) 

O 

O 

O 

O 

Referring Physician's Name 

(0008,0090) 

O 

O 

R+ 

R 

Visit Identification 

Admission ID 

(0038,00100 

O 

O 

O 

R 

Visit Status 

Current Patient Location 

(0038,0300) 

O 

0 

O 

R 

Visit Relationship 

Referenced Patient Sequence 

(0008,1120) 

o 

o 

O 

R 

>Referenced SOP Class UID 

(0008,1150) 

0 

0 

O 

R 

>Referenced SOP Instance UID 

(0008,1155) 

0 

0 

O 

R 

Patient Identification 

Patient's Name 

(0010,0010) 

R+ 

R 

R+ 

R 

Patient ID 

(0010,0020) 

R+ 

R 

R+ 

R 

Other Patient ID’s 

(0010,1000) 

O 

O 

O 

O 

Patient Demographic 

Patients Birth Date 

(0010,0030) 

O 

O 

R+ 

R 

Patient's Sex 

(0010,0040) 

O 

O 

R+ 

R 

Confidentiality constraint on 
patient data 

(0040,3001) 

O 

O 

O 

R 

Ethnic Group 

(0010,2160) 

O 

O 

O 

O 

Patient Comment 

(0010,4000) 

O 

O 

O 

O 

Patient Medical 

Patient State 

(0038,0500) 

O 

O 

O 

R 
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Pregnancy Status 

(00 10,2 ICO) 

0 

0 

o 

R 

Medical Alerts 

(0010,2000) 

o 

o 

o 

R 

Additional Patient History 

(0010.21B0) 

o 

o 

o 

O 

Contrast Allergies 

(0010,2110) 

o 

o 

0 

R 

Patient Weight 

(0010,1030) 

o 

o 

0 

R 

Special Needs 

(0038,0050) 

o 

o 

0 

R 


Note: The attribute entries marked with R+ are not required to be displayed. These attributes are 
partly needed to fulfill the requirements for attributes to be inserted in the image headers (see 
appendix C), and another part may be used to guide the settings of parameters for the image 
acquisition. Optionally these attributes may also be displayed. 

6.5.4.1.3 Expected Actions 

The Departmental System Schedule/Order Filler performs the query and sends the DICOM 
Modality Worklist to the Acquisition Modality. 

6.5.4.2 Receive Scheduled MWL Message 

This is the message that the Department System Scheduler sends to the modality as a reply 
containing DICOM Modality Worklist information. 

6.5.4.2.1 Trigger Events 

The Departmental System Scheduler/Order Filler had received a query for a MWF. 

6. 5. 4. 2. 2 Message Semantics 

C-FIND Response from the DICOM Modality Worklist SOP Class will be used for this message. 
Some of the attributes which are queried through the MWF SOP class originate with the Order 
Placer while other attributes are managed internally by the Department System Scheduler/Order 
Filler. The DSS/Order Filler will determine the Requested Procedures needed to fulfill the Order, 
and decompose the Requested Procedures in Scheduled Procedure Steps and Action Items. 

Coded Values shall be used to specify exactly what actions are to be performed at the 
Acquisition Modality. In addition to these Coded Values additional instructions for the 
technologist may be specified. It is recommended to use the Scheduled Procedure Step 
Description and the Requested Procedure Description attributes for these additional specific 
instructions. 

Appendix D defines the origin and mappings of the attributes returned in a MWF query. 

The details of the C-FIND Response from the DICOM MWF SOP Class are depicted in table 
6.5-3 and appendix C. At the time images are being created/generated, these attributes will be 
stored into the DICOM image instance headers. Additional information may be needed by the 
Acquisition Modality; however this is beyond the scope of this document. Refer to appendix A 
for a discussion of Accession Number and Procedure ID. 
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An Order may be cancelled after the corresponding Requested Procedure(s) and Scheduled 
Procedure Steps have been scheduled, and possibly even after a Performed Procedure Step has 
been started. In this case the Department System Scheduler/Order Filler shall remove the 
Scheduled Procedure Steps of the Order from its worklist, and the absence of these Scheduled 
Procedure Steps in the next C-FIND response to the Acquisition Modality will indicate that the 
procedure has been cancelled. In this way the technologist recognizes that the previously 
scheduled steps don't have to be performed. 

6.5.4.2.3 Expected Actions 

The technologist checks for the existence of the Scheduled Procedure Steps, validates the 
displayed patient and procedure information, and checks the given instructions. 

6.6 Modality Procedure Step In Progress 

This section corresponds to Transaction 6 of the IHE Technical Framework: Year 2. 

Transaction 6 is required for the Department System Scheduler/Order Filler, Image Manager, 
Performed Procedure Step Manager and Acquisition Modality actors. 

6.6.1 Scope 

This transaction includes a message from the Acquisition Modality to the Performed Procedure 
Step Manager, which in turn issues the message to the Department System Scheduler/Order 
Filler and the Image Manager that the Performed Procedure Step is in progress. This may be an 
unscheduled procedure step. The Performed Procedure Step Manager must support forwarding 
messages to two different destinations. It shall start issuing messages to the configured 
destinations immediately after it accepts the corresponding messages from the Acquisition 
Modality. 

Implementations of the Image Manager and Department System Scheduler/Order Filler shall 
include a Performed Procedure Step Manager module to forward messages to the other party. To 
allow for proper integration, the following considerations must be taken into account: 

• Performed Procedure Step Manager must maintain proper PPS objects and then store 
them until corresponding N-CREATE and N-SET messages are transmitted to both the 
Image Manager and the Department System Scheduler/Order Filler. If transmission to 
one or both destinations fails, the Performed Procedure Step Manager shall try to repeat 
transmission periodically until it succeeds. The Performed Procedure Step Manager must 
not use failure of one or more of these transmissions as a reason for rejecting the initial 
transmission from the Acquisition Modality; 

• If both the Image Manager and the Department System Scheduler/Order Filler 
incorporate the Performed Procedure Step Manager function, an infinite redistribution of 
PPS messages is possible. The Image Manager and the Department System 
Scheduler/Order Filler systems that provide the Performed Procedure Step Manager 
function shall be configurable to disable this function; 
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• When the Performed Procedure Step Manager is implemented along with the Image 
Manager or the Department System Scheduler/Order Filler, transfer of the information to 
the system it is integrated with is outside the scope of the IHE Technical Framework (i.e., 
internal to an implementation). The system with which the Performed Procedure Step 
Manager is integrated shall be considered one of the two configured destinations. 

6.6.2 Use Case Roles 



Actor: Department System Scheduler/Order Filler. 

Role: Receives the PPS information forwarded by the PPS Manager. 

Actor: Image Manager. 

Role: Receives the PPS information forwarded by the PPS Manager. 

Actor: Acquisition Modality. 

Role: Informs the Performed Procedure Step Manager that a particular Performed Procedure 
Step has started. 

Actor: Performed Procedure Step Manager. 

Role: Accepts Performed Procedure Step information from an Acquisition Modality and 
transmits it to the Department System Scheduler/Order Filler and Image Manager. 

6.6.3 Referenced Standards 

DICOM 1999 PS 3.4: Modality Performed Procedure Step SOP Class. 
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6.6.4 Interaction Diagram 


Acquisition 

Modality 


Performed Department System 

Procedure Step Scheduler/Order 

Manager Filler 


Image 

Manager 



6.6.4.1 Procedure Step In Progress Message 

6.6.4.1.1 Trigger Event 

Technologist begins procedure step from the Acquisition Modality console. 

6.6.4.1.2 Message Semantics 

The Acquisition Modality uses the Modality Performed Procedure Step SOP Class (N-CREATE 
Service) to inform the Performed Procedure Step Manager that a specific Procedure Step has 
been started and is in progress. In turn, the Performed Procedure Step Manager uses the N- 
CREATE service to forward the information to the Department System Scheduler/Order Filler 
and Image Manager. The Performed Procedure Step Manager shall use the same Performed 
Procedure Step SOP Instance UID during this interchange. The following aspects shall be taken 
into the account during implementation of this step: 

6.6.4.1.2.1 Patient/Procedure/Scheduled Procedure Step Information 

The Acquisition Modality shall ensure that the Patient/Procedure/Scheduled Procedure Step 
information it has is valid and current. 

6.6.4.1.2.2 Required Attributes 

Appendix C lists a number of attributes that have to be properly handled by the Acquisition 
Modality to ensure consistency between the Performed Procedure Step object attributes, 
Scheduled Step information in the Modality Worklist, and the information included into the 
generated images. 

6.6.4.1.2.3 Relationship between Scheduled and Performed Procedure Steps 

The relationship between Scheduled and Performed Procedure Step information is shown in the 
following 5 cases. All of these are defined by the DICOM Modality Performed Procedure Step 
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SOP Class and shall be supported by all the actors involved. Refer to appendix C for details of 
forming attributes (Study Instance UID, Procedure ID, Accession Number, etc.) in each of these 
cases. 

6.6.4.1. 2.3.1 Simple Case 



This case indicates a 1-to-l relationship between SPS and PPS. Information about the Scheduled 
Procedure Step and Requested Procedure shall be copied from the Scheduled Procedure Step 
object to the Performed Procedure Step Relationship Module (see appendix C). 

6.6.4.1 .2.3.2 Unscheduled Case 



This case indicates a 0-to-l relationship between SPS and PPS. Information about the Scheduled 
Procedure Step and, possibly, Requested Procedure is not available to the Acquisition Modality 
due to different reasons (emergency procedure, Modality Worklist SCP not available, etc.). 

The Patient ID entered on the Acquisition Modality by the technologist shall be the one created 
by the Assigning (Issuer) Authority (refer to appendix G). 

6.6.4.1 .2.3.3 Append Case 
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This is a special case of 1-to-N relationship between SPS and PPS where first the PPS is 
generated in response to an SPS. Other Performed Procedure Steps are added sequentially at a 
later time. All Performed Procedure Steps will refer back to the same Requested Procedure and 
to the original SPS. All Requested Procedure and Scheduled Procedure Step attributes shall be 
copied from the Scheduled Procedure Step Object to the Performed Procedure Step Relationship 
Module (see appendix C). 


6. 6.4. 1.2. 3.4 Group Case 


[Requested ! 

[Procedure 1 [ 

i i 

[Requested ! 

[Procedure 2 [ 


[Requested ! 

! Procedure 3 [ 

i i 



This case indicates an N-to-1 relationship between SPS and PPS. Different SPS may belong to 
different Requested Procedures or to the same one, and be fulfilled by a single Performed 
Procedure Step. Refer to section 5.5 for an example of the of the group case in a virtual image set 
split. 

All Requested Procedure and Scheduled Procedure Step attributes shall be copied from the 
multiple Scheduled Procedure Step Objects to the Performed Procedure Step Relationship 
Module in the single Performed Procedure Step (see appendix C). 


6. 6.4. 1.2. 3. 5 Abandoned Case 



This case indicates a 1-to-l relationship between SPS and PPS, even though the PPS may or may 
not create images. A procedure step may have to be abandoned for clinical reasons when only 
part of the images may have been acquired. If images are acquired and sent by the Acquisition 
Modality to the Image Archive, then they shall be identified in the PPS N-SET. This is a means 
to explicitly communicate this information to the Image Manager or Department System 
Scheduler/Order Filler. In addition, one may choose to use this abandon case to remove 
Scheduled Procedure Steps from the worklist, by starting the corresponding Performed 
Procedure Step and immediately discontinue it using the N-SET service with the status value 
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DISCONTINUED. All Requested Procedure and Scheduled Procedure Step attributes shall be 
copied from the Scheduled Procedure Step Object to the Performed Procedure Step Relationship 
Module (see appendix C). 

6.6.4.1.2.4 Protocol Handling 

The protocol (a specific combination of modality settings) used in performing a procedure step 
shall be determined on the Acquisition Modality at this time. Two cases/options are defined: 
Manual Modality Setting and Assisted Modality Setting. The first case is the one that is currently 
most commonly used while the second case introduces new functionality and is optional for the 
IHE Technical Framework: Year 2. 

The Acquisition Modality shall not change the Procedure Code it obtains through the MWL. If 
the Procedure Code is not correct or needs to be changed at the time the procedure is being 
performed, one of the following two methods shall be used: 

• The Procedure Information should be corrected on the Department System 
Scheduler/Order Filler, and updated information to be downloaded to the Acquisition 
Modality, OR 

• The Acquisition Modality redefines Action Item Codes for the Procedure Steps it actually 
performs and sets the Procedure Code Sequence (0008,1032) to 0 length. 

6.6.4.1. 2.4.1 Manual Modality Setting 

The following illustration is a Scheduled Procedure Step (SPS) being returned to an Acquisition 
Modality as part of a Modality Worklist (MWL) and protocol information being returned in the 
Performed Procedure Step (PPS). In this case an operator selects and sets a protocol based on 
manual interpretation/evaluation of the Requested Procedure (RP) code and/or the Scheduled 
Procedure Step Action Item Code (AIC) and description. 



6.6.4.1 .2.4.2 Assisted Modality Setting. 

The following illustrates a Scheduled Procedure Step (SPS) being returned to an Acquisition 
Modality as part of a Modality Worklist (MWL) and protocol information being returned in the 
Performed Procedure Step (PPS) utilizing codes. In this case, the operator may accept the 
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protocol proposed by the incoming Action Item code, or select a protocol from a table rather than 
manually entering the protocol as in the Manual Modality Setting. 


RP — Code & Desc. 


Code/Protocol 


SPS 


SPS AI — AIC&Desc. 


► 


MWL 




A 

performed . . . 



X 

suggested . . . 


Performed Protocol; AI code 


PPS 



Operator accepts 
suggested protocol 
or selects protocol 
from table 


► 


Notes: AI Code/Protocol table will need to be configured on the Acquisition Modality. This 
table will also need to be synchronized with the Image Manager and the Departmental System 
Scheduler/Order Filler. If a requested AI Code is not defined, the Acquisition Modality must 
alert the operator. 

6.6.4.1.3 Expected Actions 

The DS S/Order Filler receives information from the Performed Procedure Step Manager and 
links it with the Requested Procedure and Scheduled Procedure Step. If the Requested Procedure 
ID is transmitted empty (Unscheduled Performed Procedure Step case), the Department System 
Scheduler/Order Filler and the Image Manager will create an exception which must be manually 
resolved to link the Performed Procedure Step to the appropriate procedure. 

6.7 Modality Procedure Step Completed 

This section corresponds to Transaction 7 of the IHE Technical Framework: Year 2. 

Transaction 7 is required for the Department System Scheduler/Order Filler, Image Manager, 
Performed Procedure Step Manager and Acquisition Modality actors. 

6.7.1 Scope 

This transaction includes a message from the Acquisition Modality to the Performed Procedure 
Step Manager, which in turn issues messages to the DSS/Order Filler and the Image Manager 
that the Performed Procedure Step has been completed. Information is not being released for 
billing at this point but a code may be assigned. The Image Manager may need the information to 
co-locate images of the same study. The Modality Procedure Step Completed message does not 
necessarily mean that the set of images is complete or available for retrieval. 
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6.7.2 Use Case Roles 



Actor: Departmental System Scheduler/Order Filler. 

Role: Receives the PPS information forwarded by the PPS Manager. 

Actor: Image Manager. 

Role: Receives the PPS information forwarded by the PPS Manager. . 

Actor: Acquisition Modality. 

Role: Informs the Performed Procedure Step Manager that a particular Performed Procedure 
Step is completed. 

Actor: Performed Procedure Step Manager. 

Role: Accepts Performed Procedure Step information from an Acquisition Modality and 
transmits it to the Department System Scheduler/Order Filler and the Image Manager. 


6.7.3 Referenced Standards 

DICOM 1999 PS 3.4: Modality Performed Procedure Step SOP Class. 
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6.7.4 Interaction Diagram 


Acquisition Performed Department System Image 

Modality Procedure Step Scheduler/Order Manager 

Manager Filler 



Note: The diagram above shows the sequencing of messages for the Modality Performed 
Procedure Step SOP Class. Acquisition Modalities will also implement the Storage and Storage 
Commitment classes. The timing relationship between PPS messages and Storage and Storage 
Commitment messages is not specified. That is, PPS messages may occur before or after storage 
requests. 

6.7.4.1 Procedure Step Completed/Discontinued 

6.7.4.1.1 Trigger Event 

Technologist completes procedure step from the Acquisition Modality console. 

6.7.4.1.2 Message Semantics 

The Acquisition Modality uses the Modality Performed Procedure Step SOP Class (N-SET 
service) to inform the Performed Procedure Step Manager that a specific Performed Procedure 
Step has been completed or discontinued. The Acquisition Modality may use the MPPS N-SET 
service to send intermediate updates of the Performed Procedure Step information. 

The final N-SET has either the MPPS status of "COMPLETED" or "DISCONTINUED". The 
Performed Procedure Step Manager sends corresponding N-SETs to the Department System 
Scheduler/Order Filler and Image Manager. 

Along with other information, the Acquisition Modality shall transmit information about the 
protocol it used to produce images to the recipients. See Protocol Handling in section 6. 6. 4. 1.2.4 
for detailed discussion of this issue. 

6.7.4.1 .2.1 .1 Retrieve AE Title 

According to the DICOM Standard, the Acquisition Modality has the ability to include the 
Retrieve AE Title attribute (0008,0054) in the Performed Series Sequence (0040,0340). This is 
an AE Title where the referenced image instances for the series may be retrieved. This Retrieve 
AE Title will often be of zero length or be of short-term validity, due to the following situations: 
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• If an Acquisition Modality supports a Retrieve SOP Class in an SCP Role, the modality 
Retrieve AE Title may be included; however, the modality does not guarantee long-term 
availability. 

• A Retrieve AE Title of the Image Manager can be configured on the Acquisition 
Modality. Otherwise, this field should be sent zero length. Acquisition Modality 
implementers should not assume that the destination AE Title used for the Storage SCP 
or Storage Commitment SCP is the same as that for Image Retrieval. 

• An Acquisition Modality may receive the Retrieve AE Title in a Storage Commitment 
Message (N-EVENT REPORT). However, this information may be received well after 
the MPPS N-SET (Complete) was performed. 

6.7.4.1.3 Expected Actions 

The Image Manager and Department System Scheduler/Order Filler receive information about 
the Performed Procedure Step being complete or discontinued. The Image Manager and 
Department System Scheduler are not required to act on intermediate N-SET messages with the 
MPPS Status "IN PROGRESS". 

The Requested Procedure may be considered complete if all Performed Procedure Steps related 
to all Scheduled Procedure Steps have been completed (or properly discontinued). Additional 
new (unscheduled) Performed Steps may be performed at any time, even after the Requested 
Procedure has been assigned complete scanning status. See relationship between Scheduled and 
Performed Procedure Steps in section 6.6.4. 1.2.3 for detailed discussion of this issue. 

6.8 Modality Images Stored 

This section corresponds to Transaction 8 of the IHE Technical Framework: Year 2. Transaction 
8 is required for the Image Archive and Acquisition Modality. 

6.8.1 Scope 

In the Modality Images Stored transaction, the Acquisition Modality sends the acquired images 
to the Image Archive. The information provided from the Modality Worklist transaction (see 
section 6.5) will be included in the headers of the generated images. 

6.8.2 Use Case Roles 
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Actor: Acquisition Modality 

Role: Transmit acquired image data to Image Archive. 
Actor: Image Archive 

Role: Accept and store images from Acquisition Modalities. 

6.8.3 Referenced Standards 

DICOM 1999 PS 3.4: Storage Service Class. 

6.8.4 Interaction Diagram 


Acquisition Image 

Modality Archive 



6.8.4.1 Images Stored 

6.8.4.1.1 Trigger Events 

The Acquisition Modality can transfer images to the Image Archive sequentially within one or 
more DICOM associations, as the images become available or collectively. 

6.8.4.1.2 Message Semantics 

The Acquisition Modality uses the DICOM C-STORE message to transfer the images. The 
Acquisition Modality is the DICOM Storage SCU and the Image Archive is the DICOM Storage 
SCP. 

The technologist validates the available information for the patient and the Scheduled Procedure 
Step/Requested Procedure. It is a requirement that certain information be recorded in the image 
header. The details of the mapping to DICOM image instances are depicted in appendix C. 
Effectively, this appendix strengthens the type definition of some DICOM attributes for the IHE 
Technical Framework: Year 2. 
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6.8.4.1.3 Expected Actions 

The Image Archive will store the received DICOM objects. 

6.8.4.1.3.1 DICOM Image Storage SOP Classes 

The DICOM Standard (1999) defines a number of image specific storage SOP classes. It is 
expected that Image Archive will support multiple storage SOP classes as defined in table 6.8-1 
below. 


Table 6.8-1. Suggested Image SOP Classes 


SOP Class UID 

SOP Class Name 

1.2.840.10008.5.1.4.1.1.1 

Computed Radiography Image Storage 

1.2.840.10008.5.1.4.1.1.2 

CT Image Storage 

1.2.840.10008.5.1.4.1.1.4 

MR Image Storage 

1.2.840.10008.5.1.4.1.1.20 

Nuclear Medicine Image Storage 

1.2.840.10008.5.1.4.1.1.128 

Positron Emission Tomography Image Storage 

1.2.840.10008.5.1.4.1.1.481.1 

RT Image Storage 

1.2.840.10008.5.1.4.1.1.7 

Secondary Capture Image Storage 

1.2.840.10008.5.1.4.1.1.6.1 

Ultrasound Image Storage 

1.2.840.10008.5.1.4.1.1.3.1 

Ultrasound Multi-frame Image Storage 

1.2.840.10008.5.1.4.1.1.12.1 

X-Ray Angiographic Image Storage 

1.2.840.10008.5.1.4.1.1.12.2 

X-Ray Radiofluoroscopic Image Storage 

1.2.840.10008.5.1.4.1.1.1.1 

Digital X-Ray Image Storage - For Presentation 

1.2.840.10008.5.1.4.1.1.1.1.1 

Digital X-Ray Image Storage - For Processing 

1.2.840.10008.5.1.4.1.1.1.2 

Digital Mammography Image Storage - For Presentation 

1.2.840.10008.5.1.4.1.1.1.2.1 

Digital Mammography Image Storage - For Processing 

1.2.840.10008.5.1.4.1.1.1.3 

Digital Intra-oral X-Ray Image Storage - For Presentation 

1.2.840.10008.5.1.4.1.1.1.3.1 

Digital Intra-oral X-Ray Image Storage - For Processing 

1.2.840.10008.5.1.4.1.1.77.1.1 

VF Endoscopic Image Storage 

1.2.840.10008.5.1.4.1.1.77.1.2 

VF Microscopic Image Storage 

1.2.840.10008.5.1.4.1.1.77.1.3 

VF Slide-Coordinates Microscopic Image Storage 

1.2.840.10008.5.1.4.1.1.77.1.4 

VF Photographic Image Storage 


6.9 Modality Presentation State Stored 

This section corresponds to Transaction 9 of the IHE Technical Framework: Year 2. Transaction 
9 is required for the Image Archive Actor and is optional for the Acquisition Modality Actor. 

6.9.1 Scope 

This section describes DICOM Storage requests of Grayscale Softcopy Presentation States 
issued by the Acquisition Modality to the Image Archive. The Acquisition Modality sends 
Presentation States for storage along with the images so they can be later used for support of 
consistent display of imaging data. The Acquisition Modality will be the DICOM Storage SCU 
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and the Image Archive will be the DICOM Storage SCP. DICOM Supplement 33: Grayscale 
Softcopy Presentation State Storage defines the transformations required for this transaction. 

6.9.2 Use Case Roles 



Actor: Acquisition Modality 

Role: Generate Grayscale Softcopy Presentation States to be applied to image data. This actor 
will support the ability to send Presentation State data to an Image Archive. This actor must 
support pixel rendering according to the Grayscale Standard Display Function (GSDF) as 
defined in DICOM 1999 PS 3.14. 

Actor: Image Archive 

Role: Accept and store Grayscale Softcopy Presentation State SOP Instances received from the 
Acquisition Modality. 

6.9.3 Referenced Standards 

DICOM 1999 PS 3.4: Storage Service Class 

DICOM Supplement 33: Grayscale Softcopy Presentation State Storage (Final Text 21 
September 1999) 

DICOM 1999 PS 3.14: Grayscale Standard Display Function 
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6.9.4 Interaction Diagram 


Acquisition Image 

Modality Archive 



6.9.4.1 Modality Presentation State Stored 

6.9.4.1.1 Trigger Events 

The Acquisition Modality generates a Grayscale Softcopy Presentation State and sends it to the 
Image Archive for storage. 

6.9.4.1.2 Message Semantics 

The Acquisition Modality uses the DICOM C-STORE message to store Grayscale Softcopy 
Presentation States. Message semantics are defined in the Grayscale Softcopy Presentation State 
Storage SOP Class Behavior section of the DICOM Standard (DICOM Supplement 33). 

6.9.4.1.3 Expected Actions 

The Image Archive will store the received Grayscale Softcopy Presentation State objects. 

6.10 Modality Storage Commitment 

This section corresponds to Transaction 10 of the IHE Technical Framework: Year 2. 
Transaction 10 is required for the Image Manager and Acquisition Modality actors. 

6.10.1 Scope 

In the Modality Images Stored and/or the Modality Presentation States Stored transaction, the 
Acquisition Modality has sent the acquired images and/or generated Presentation States of a 
study to the Image Archive. In this Modality Storage Commitment transaction the Acquisition 
Modality requests that the Image Manager/Image Archive accept responsibility for the images 
and/or Presentation States. The objective of this transaction is to provide a formal release of 
storage responsibility by the Acquisition Modality, allowing it to reuse its internal resources 
allocated to the study. 


Rev. 4.0 
03-28-2000 


103 


Copyright © 2000: HIMSS/RSNA 





IHE Technical Framework: Year 2 


6.10.2 Use Case Roles 



Actor: Acquisition Modality 

Role: Make requests for storage commitment to the Image Manager for the images and/or 
Presentation States previously transmitted. 

Actor: Image Manager. 

Role: Assume responsibility for reliable storage, retrieval, and validity of image data and 
Presentation States. 

6.10.3 Referenced Standards 

DICOM 1999 PS 3.4: Storage Commitment Push Model SOP Class. 

6.10.4 Interaction Diagram 


Acquisition 

Modality 


Image 

Manager 


Storage Commitment 
N- ACTION 

► 

Storage Commitment 
N-EVENT-REPORT 

◄ 


I 

I 
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6.10.4.1 Images Committed 

The Storage Commitment Push Model SOP Class shall be used as reflected in the interaction 
diagram. The Storage Commitment Pull Model SOP Class will not be supported. Refer to the 
DICOM 1999 PS 3.4 for detailed descriptive semantics. 

6.10.4.1.1 Trigger Events 

The Acquisition Modality is the Storage Commitment SCU and can issue a commitment request 
at any time after the successful transfer of one or more SOP Instances to the Image Manager, 
which is the Storage Commitment SCP. 

6.10.4.1.2 Message Semantics 

The Acquisition Modality uses the DICOM Storage Commitment SOP Class to communicate 
with the Image Manager. The Acquisition Modality shall not use the Referenced Study 
Component Attribute because the Modality Performed Procedure Step will be used for this 
purpose. The Storage Commitment AE Title used by the Image Manager may or may not be the 
same AE Tile as the one used for the Images Stored (C-STORE) service. The Acquisition 
Modality shall support this flexibility with respect to the AE Title. The N-EVENT-REPORT sent 
by the Image Manager to communicate its storage commitment may or may not occur on the 
same association as the N-ACTION. 

An Acquisition Modality may receive the Retrieve AE Title in a Storage Commitment Message 
(N-EVENT REPORT). However, this N-EVENT REPORT may happen well after the Modality 
Performed Procedure Step N-SET (Complete) was performed. For this reason, the IHE 
Technical Framework: Year 2 does not require that the Acquisition Modality send the Retrieve 
AE Title Attribute (0008,0054) in the Modality Performed Procedure Step N-SET (See section 
6.7). 

Under normal circumstances, in the event that the Image Manager cannot service the storage 
commitment request, which can be determined by the "Failure Reason Attribute," the 
Acquisition Modality shall not delete nor modify the respective SOP instance. 

6.10.4.1.3 Expected Actions 

The Image Manager in coordination with the Image Archive accepts responsibility for the safe 
storage of the transferred image data or Presentation States. (The form of the cooperation is 
beyond the scope of the IHE Technical Framework.) Ownership of data transfers from the 
Acquisition Modality to the Image Manager. The Acquisition Modality is then free to manage its 
own internal resources accordingly. 

6.11 Image Availability Query 

This section corresponds to Transaction 11 of the IHE Technical Framework: Year 2. 

Transaction 1 1 is required for the Department System Scheduler and Image Manager actors. 
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6.11.1 Scope 

The purpose of this transaction is for the Department System Scheduler/Order Filler to determine 
whether images associated with a particular performed procedure step have been stored and are 
available for use in subsequent workflow steps as well as the storage location for retrieval of 
these images. The Image Manager is assumed to possess image availability information. The 
following examples show possible uses of the Image Availability Query: 

• The Department System Scheduler/Order Filler queries the Image Manager after 
receiving notification that images have been acquired (by MPPS N-SET message with 
PPS status of “COMPFETED” - see Transaction 7) until it receives a list of all images 
listed in the PPS. 

• The Department System Scheduler/Order Filler needs to verify the availability of prior 
images pre-fetched according to workflow rules. In this case the availability of a single 
image may have to be verified. 

Image availability is determined by the fact that the Image Instance UID in question is returned 
in response to the query. However, for the purposes of workflow management, image availability 
shall also be qualified with two additional parameters: 

Storage Location describes a system or system component (for instance, an Image Archive) 
which can be identified as a holder of images at a particular period in time. 

Access Time is a period of time that is required for images to be moved from a storage location 
to be ready for distribution; i.e., this does not take into consideration the outbound 
network transfer time nor the performance of the receiver application to display the 
images. The exact access time is difficult to determine and is highly implementation- 
dependent. Nevertheless, it is possible to approximate access time by using a degree or 
level of image availability. 

6.1 1 .2 Use Case Roles 



Actor: Department System Scheduler/Order Filler 


Role: Queries Image Manager to determine availability of images for use in the processes 
according to department workflow (for example, interpretation) 

Actor: Image Manager 
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Role: Supplies image availability information to Department System Scheduler/Order Filler 

6.11.3 Referenced Standards 

DICOM 1999 PS 3.4: Query/Retrieve Service Class. 

6.11.4 Interaction Diagram 

Department System 

Scheduler/Order Filler Ima § e Mana 8 er 



6.1 1 .4.1 Query Image Availability 

6.11.4.1.1 Trigger Events 

After receiving MPPS N-SET message with PPS status of “COMPFETED” or at a later time, the 
Department System Scheduler/Order Filler needs to verify image availability. 

6.1 1 .4.1 .2 Message Semantics 

The Department System Scheduler/Order Filler issues a C-FIND request as specified in the 
DICOM Standard for the Study Root Query/Retrieve Information Model - FIND SOP Class. 

The Department System Scheduler/Order Filler must be configured with the AE information of 
the Image Managers to be queried. To obtain the list of images in question, the Department 
System Scheduler/Order Filler shall perform a query on the Image Fevel based on the 
specification in DICOM. The Hierarchical Search Method shall be supported. The following 
table highlights important attributes of the query. It is not the intent of this transaction to provide 
a mechanism for polling. The Department System Scheduler/Order Filler shall query the Image 
Manager with the minimal number of queries necessary. For example, if the purpose is to verify 
availability of all images in a series, DSS/OF shall not send queries on an image-by-image basis. 
In this case, a single, zero length value for the SOP Instance UID could be sent, then all matched 
images information will be returned. 


Table 6.11-1. Images Availability Query Keys 


Attribute 

Tag 

Query Key value 

Query/Retrieve Level 

(0008,0052) 

IMAGE 

Study Instance UID 

(0020.0010) 

Unique value for single-value match 
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Series Instance UID 

(0020.000E) 

Unique value for single-value match 

SOP Instance UID 

(0008.0018) 

Single value, zero length value or list of UIDs 


Per the DICOM standard. Retrieve AE Title (0008,0054) shall be supported and returned by the 
Image Manager as part of the response. 

To better quantify Access Time, IHE has proposed the addition of the attribute Image Access 
Time with enumerated values of “ON-LINE'’, “NEAR-LINE” and “OFF-LINE” in a DICOM 
Change Proposal (CP 191). This is not part of the IHE Technical Framework: Year 2, but will be 
incorporated into future versions when the correction proposal to the DICOM standard is 
approved. In terms of access times and results of subsequent Retrieve (C-MOVE) request, the 
Image Availability values shall be interpreted as follows: 


Table 6.11-2. Image Access Time 


Level 

Description 

Access time 

ON-LINE 

Images can be retrieved from storage location and be ready for 
distribution within a reasonable period of time (what time is 
reasonable is implementation-specific) 

Typically, seconds to few minutes 

NEAR-LINE 

Before distribution, images has to be processed at a storage 
location; total retrieval time is longer than “reasonable” 

Typically, minutes to an hour 

OFF-LINE 

Image cannot be distributed without human user intervention 

Typically, minutes to hours to 
days 


6.11.4.1.3 Expected Actions 

The Image Manager shall respond to the C-FIND as specified in the DICOM standard, including 
returning the SOP Instance ETIDs (0008,0018) and corresponding Retrieve AE title (0008, 0054) 
when the match is successful. 

6.12 Patient Update 

This section corresponds to Transaction 12 of the Technical Framework: Year 2. Transaction 12 
is required for the ADT, Order Placer, Department System Database and Image Manager actors. 

6.12.1 Scope 

This transaction involves changes to patient information, including demographics, patient 
identification, patient location/class changes, and patient merges. These changes may occur at 
any time for a patient record. This transaction is used for both inpatients (i.e., those who are 
assigned a bed at the facility) and outpatients (i.e., those who are not assigned a bed at the 
facility) if the patient has been previously registered. 
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6.12.2 Use Case Roles 



Actor: ADT 

Role: Adds and modifies patient demographic and encounter information. 

Actor: Order Placer 

Role: Receives patient and encounter information for use in order entry. 

Actor: Department System Database 

Role: Receives and updates patient and encounter information to maintain consistency with 
ADT and MPI systems. Shall provide the updated patient and encounter information to the 
Image Manager. 

Actor: MPI 

Role: Receives patient and encounter information from multiple ADT systems. Maintains 
unique enterprise-wide identifier for a patient. 

Actor: Image Manager 

Role: Receives patient and encounter information for use in maintaining image database and, 
possibly, for image management such as autorouting to a specific in-patient floor. 

Note: IHE Technical Framework: Year 2 does not support the use of a Master Patient Index 
which is required for synchronization of patient information between multiple ADT systems 
employed by a healthcare enterprise. It is expected that the IHE initiative will include an MPI 
Actor in the future and that the Patient Update/Merge Transaction between the ADT and MPI 
will be similar to the transaction between the ADT and Order Placer and Order Filler actors. 

6.12.3 Referenced Standards 

HL7 2.3.1 Chapters 2, 3 
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6.12.4 Interaction Diagram 


Order Department System Image 
ADT Placer Database Manager MPI 



6.12.4.1 Patient Management - Update Patient 

6.12.4.1.1 Trigger Events 

Changes in patient location result in the following Update Patient message: 

A02 - Patient Transfer 

An A02 event is issued as a result of the patient changing his or her assigned physical location. 

Changes in patient class (that is from an inpatient status to outpatient, from an outpatient status 
to inpatient, from “admitted” or “non-admitted” status to discharged) result in one of the 
following Update Patient messages: 

• A03 - Patient Discharge 

• A06 - Change an Outpatient to an Inpatient 

• A07 - Change an Inpatient to an Outpatient 

An A03 event signals the end of a patient’s stay in a healthcare facility. For in-patient, it signals 
that the patient’s status has changed to “discharged” and the patient is no longer in the facility. 
For outpatient, it signals the end of current visit of a patient to the facility. An A06 event is sent 
when a patient who was present for a non-admitted visit is being admitted. This event changes a 
patient’s status from non-admitted to admitted. An A07 event is sent when a patient who was 
admitted changes his/her status to “no longer admitted” but is still being seen for this episode of 
care. This event changes a patient from an “admitted” to a “non-admitted” status. 

Changes to patient demographics and account information (e.g., change in patient name, patient 
address, etc.) shall trigger the following Update Patient message: 

• A08 - Update Patient Information 

Resolution of the situation where two patient records are found to identify the same person, shall 
trigger the following Merge Patient messages: 

• A40 - Merge Patient - Internal ID 
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An A40 message indicates that a merge has been done at the internal identifier level. That is, 
PID-3-patient ID identifier has been merged with MRG-1 Patient ID. This message is initiated 
by the system that performs the merge. 

6.12.4.1.2 Message Semantics 

The Update Patient transaction is an HL7 ADT message. The message shall be generated by the 
system that performs the update whenever an error is resolved or a change occurs in patient 
demographics, patient class changes, patient location, or whenever two patient records are 
identified to be the same person. 

The segments of the Update Patient Class and Patient Transfer messages listed below are 
required, and the detailed description of messages is provided in sections 6.12.4.1.2.1 through 
6.12.4.1.2.3. 


ADT 

A02/A03/A06/A07 

Patient Administration 
Message 

Chapter in HL7 
V2.3.1 

MSH 

Message Header 

2 

EVN 

Event Type 

3 

PID 

Patient Identification 

3 

PV1 

Patient Visit 

3 


The segments of the Update Patient Information message listed below are required, and the 
detailed description of the message is provided in section 6.12.4.1.2.4. The allergy segment AL1 
is optional. 


ADT A08 

Patient Administration 
Message 

Chapter in HL7 
V2.3.1 

MSH 

Message Header 

2 

EVN 

Event Type 

3 

PID 

Patient Identification 

3 

PV1 

Patient Visit 

3 

[ {AL1 j ] 

Allergy 

3 


The segments of the Merge Patient message listed below are required, and the detailed 
description of the message is provided in section 6.12.4.1.2.5. The PV1 segment is optional. 


ADT A40 

Patient Administration 
Message 

Chapter in HL7 
V2.3.1 

MSH 

Message Header 

2 

EVN 

Event Type 

3 

PID 

Patient Identification 

3 

MRG 

Merge Information 

3 

[PV1] 

Patient Visit 

3 
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The Patient Update transactions shall be acknowledged by the HL7 ACK message sent from the 
receiver of ADT message to its sender, as defined in section 6.1. 

The MSH segment description is given in table 6.1-1; however, the second component of Field 
MSH-9 Message Type shall have the value A02, A03, A06, A07, A08, or A40, as appropriate. 

The EVN segment description is given in table 6.1-2. 

6.12.4.1.2.1 Patient Transfer message (A02) 

Refer to table 6.1-3 for the PID segment and to table 6.1-4 for the PV1 segment definitions. 

The “Patient Transfer” (A02) message changes shall include: 

The new patient location shall appear in PVl-3-assigned patient location while the old 
patient location shall appear in PV 1 -6-prior patient location. 

6.12.4.1.2.2 Update Patient Discharge message (A03) 

Refer to table 6.1-3 for the PID segment and to table 6.1-4 for the PV1 segment definitions. 

The “Patient Discharge” (A03) message changes shall include: 

The patient’s location prior to discharge shall be entered in PVl-3-assigned patient location. 

If the patient is an outpatient, PV 1-45-discharge date/time shall be used for the visit end 
date/time. 

6.12.4.1.2.3 Update Patient Class messages (A06/A07) 

Refer to table 6.1-3 for the PID segment and to table 6.1-4 for the PV1 segment definitions. 

The “Change an Outpatient to an Inpatient” (A06) message changes shall include: 

• The new patient class shall appear in PVl-2-patient class. 

• The new patient location shall appear in PVl-3-assigned patient location. 

• The old patient location (if relevant) shall appear in PV1 -6-prior patient location. 

• The current active account number shall appear in PID- 18-patient account number. 

• The Attending Doctor in PV 1-7, the Referring Doctor in PV1-8, and the Consulting 
Doctor in PV1-9, may be different, if there are changes to those values. 

The “Change an Inpatient to an Outpatient” (A07) message changes shall include: 

• The new patient class shall appear in PVl-2-patient class. 

• The old patient location shall appear in PV1 -6-prior patient location. 

• The current active account number shall appear in field PID- 18-patient account number. 

• The Attending Doctor in PV 1-7, the Referring Doctor in PV1-8, and the Consulting 
Doctor in PV1-9, may be different, if there are changes to those values. 

A06 and A07 messages shall be used exclusively to send fields pertinent to the change in patient 
class between inpatient and outpatient. 


112 

Rev. 4.0 Copyright © 2000: HIMSS/RSNA 

03-28-2000 



IHE Technical Framework: Year 2 


Modification of any patient demographic information or non patient-class visit information must 
be done by in addition sending an Update Patient Information (A08) message. 

6.12.4.1.2.4 Update Patient Information message (A08) 

The required fields of the PID, PV1, and AL1 segments are given in tables 6.1-3 through 6.1-5, 
respectively. All of the required (R and R2) information for a patient record shall be re-sent in 
an A08 message. Any information received as null (non-existent) in the A08 message shall be 
removed from the receiving system's database for that patient record. 

An A08 message is the only method that may be used to update patient demographic and visit 
information. However Patient ID cannot be updated with an A08 message. An A40 message 
shall be used for this purpose (see section 6.12.4.1.2.5). 

6.12.4.1.2.5 Merge Patient message (A40) 

The required fields of the PID and PV1 segments are given in section 6.1, tables 6.1-3 and 6.1-4, 
respectively. The MRG segment is given in table 6.12-1 below. 

The PID and PV 1 segments contain the dominant patient information, including Patient ID (and 
Issuer of Patient ID). The MRG segment identifies the “old” or secondary patient records to be 
de-referenced. HL7 does not require that the 'old' record be deleted; it does require that the 
"incorrect" identifier is never referenced in future transactions following the merge. 

A separate merge message shall be sent for each patient record to be merged. For example, if 
Patients A, B, and C are all to be merged into Patient B, two MRG messages would be sent. In 
the first MRG message patient B would be identified in the PID segment, and Patient A would be 
identified in the MRG segment. In the second MRG message, patient B would be identified in 
the PID segment, and Patient C would be identified in the MRG segment. 

Modification of any patient demographic information should be done by sending a separate 
Update Patient Information (A08) message for the current Patient ID. An A40 message is the 
only method that may be used to update a Patient ID. 

A new Patient shall be created in the Image Manager using the demographics contained in the 
Patient Merge (A40) message when the prior Patient to be merged does not exist on the Image 
Manager. This should be followed by a Patient Update (A08) Message to update any of the 
demographics missing in the Patient Merge (A40) message. 


Table 6.12-1. IHE Profile - MRG segment 


SEQ 

LEN 

DT 

OPT 

TBL# 

ITEM# 

ELEMENT NAME 

1 

20 

cx 

R 


00211 

Prior Patient Identifier List 

2 

20 

cx 

o 


00212 

Prior Alternate Patient ID 

3 

20 

cx 

o 


00213 

Prior Patient Account Number 

4 

20 

cx 

R2 


00214 

Prior Patient ID 

5 

20 

cx 

o 


01279 

Prior Visit Number 

6 

20 

cx 

o 


01280 

Prior Alternate Visit ID 
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7 

48 

XPN 

R2 


01281 

Prior Patient Name 


Adapted from the HL7 Standard, version 2.3.1 

Modification of any patient demographic information or non patient-class visit information must 
be done by in addition sending an Update Patient Information (A08) message. 

6.12.4.1.3 Expected Actions 

For a Patient Transfer, Patient Discharge, or Patient Class message (A02/A03/A06/A07) it is 
expected that the receiving system will change its local patient visit information. 

For a Patient Information message (A08) it is expected that the receiving system will update its 
local patient demographic, visit, allergy, and/or insurance information. Any information 
received as null or blank in the new A08 message should be removed locally. 

For a Patient Merge message (A40) it is expected that the receiving system will perform updates 
to reflect the fact that two patient records have been merged into a single record. 

6.12.4.2 Patient Management - Cancel Patient Transfer/Discharge 

6.12.4.2.1 Trigger Events 

The following events will trigger one of the Cancel messages: 

• A12 - Transfer of a patient from one location to another has been cancelled due to error 
in the information or the decision not to transfer patient after all. 

• A13 - Discharge of a patient has been cancelled due to error in the information or the 
decision not to discharge patient after all. 

6.12.4.2.2 Message Semantics 

Patient Transfer/Discharge conveyed by the HF7 ADT A A02 or ADT A A03 may have to be 
revoked due to the errors in the information or the decision of not transferring/discharging 
patient. Cancellation transaction is conveyed by the HF7 ADT A A12 or ADT A A13 messages. 
ADT A A12 shall be used to revoke transaction conveyed by ADT A A02 message. ADT A A13 shall 
be used to revoke transaction conveyed by the ADT A A03 message. 

6.12.4.2.3 Expected Actions 

If the patient record was modified as a result of Patient Transfer/Discharge transaction, it shall be 
reverted. 

6.13 Procedure Update 

This section corresponds to Transaction 13 of the IHE Technical Framework: Year 2. 

Transaction 13 is required for the Department System Scheduler/Order Filler and Image 
Manager Actors. 
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6.13.1 Scope 

This transaction involves changes to procedure information communicated from Department 
System Scheduler to the Image Manager. Unlike the order ORM message sent between the 
Order Placer and Order Filler (where only the order status can be updated without requiring a 
Cancel/New Order to change an order), the ORM message from the Department System 
Scheduler/Order Filler and Image Manager can be a previously scheduled Requested Procedure 
identified by a Study Instance UID. 

6.13.2 Use Case Roles 



Actor: Department System Scheduler/Order Filler 

Role: Responsible for scheduling placed orders and sending the timing, resource, procedure and 
other information to the Image Manager. 

Actor: Image Manager 

Role: May use the scheduling, resource, procedure, and other information to perform image 
management tasks such as autorouting or prefetching of images. 

6.13.3 Referenced Standards 

HF7 2.3.1 Chapters 2, 4 

6.13.4 Interaction Diagram 

Department System Image 

Scheduler/Order Filler Manager 
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6.13.4.1 Trigger Events 

A Procedure Update transaction is triggered in the case when the Department System Scheduler 
cancels, re-schedules or modifies characteristics of the procedure it previously scheduled and 
transmitted to the Image Manager via a Procedure Scheduled transaction (Transaction 4). 

6.13.4.2 Message Semantics 

The Procedure Update transaction is conveyed by the HL7 ORM message formatted according to 
the rules described in section 6.4. MSH-9 shall contain the value “ORM”. 

The following Order Control Codes are applicable for use in the field ORC-1. 


Table 6.13-1. IHE Profile - Required Order Control Codes 


Value 

Description 

Originator 

CA 

Cancel order request 

DSS 

XO 

Change order request 

DSS 

DC 

Discontinue order request 

DSS 


Adapted from the HL7 Standard, version 2.3.1 

Only procedural information that is conveyed in the OBR and ORC segments of the message 
may be changed. Any updates of patient or visit information shall be performed by Transaction 
12, Patient Update (see sections 6.1 and 6.12 for PID and PV1 information and updates). 

The ORC and OBR elements given in table 6.13-2 shall not be altered after the initial Procedure 
Scheduled (section 6.4), regardless of the type of control code. 


Table 6.13-2. Procedure Update Elements that should not be changed 


Element Name 

Element Number(s) 

Placer Order Number 

OBR-2, ORC-2 

Filler Order Number 

OBR-3, ORC-3 

Placer Group Number 

ORC-4 

Study Instance UID 

ZDS-1 


Any other elements in the OBR or ORC segments may be changed when the Order Control 
Code = XO. 

Note: Additional information regarding HL7 conventions, profiling, and implementation 
considerations are given in section 2.3. 

6.13.4.3 Expected Actions 

The Image Manager is expected to perform the following actions on the value of the field ORC-1 
Order Control Code : 

CA - Procedure has been cancelled, usually due to the cancellation of the underlying order; the 
Image Manager shall inactivate corresponding procedure information using Study Instance UID 
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as a unique key of the procedure in question. Information from PID and PV 1 segments shall not 
be used to update patient or visit information. If the Department System Scheduler/Order Filler 
has been notified that a Performed Procedure Step is in progress for a Requested Procedure, the 
order control code DC should be used. 

XO - Procedure-related information (including scheduled date/time and/or resource) has been 
changed. The Image Manager shall modify corresponding procedure information using the 
Study Instance UID as a unique key of the procedure in question. Information from PID and PV 1 
segments shall not be used to update patient or visit information. 

DC - Order to which the particular procedure is related has been discontinued after at least one 
Performed Procedure Step for this procedure has started. The Image Manager shall consider all 
remaining SPS known for that procedure (if any) cancelled. The Image Manager shall use the 
Study Instance UID as a unique key of the procedure in question. Information from PID and PV 1 
segments shall not be used to update patient information. 

6.14 Query Images 

This section corresponds to Transaction 14 for the IHE Technical Framework: Year 2. 
Transaction 14 is required for the Image Archive and Image Display actors. 

6.14.1 Scope 

The Image Display queries the Image Archive for study, series and image instances for retrieval. 

6.14.2 Use Case Roles 



Actor: Image Archive 

Role: Responds to queries for Studies, Series, Images. 
Actor: Image Display 

Role: Issues Queries for Studies, Series, Images 

6.14.3 Referenced Standards 

DICOM 1999 PS 3.4: Query/Retrieve Service Class 
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6.14.4 Interaction Diagram 

Image Manager Image 

Display 


Query Images (C-FIND) 


Query Responses (C-FIND) 

► 


6.14.4.1 Query Images 

The Query (Study Root - FIND and optionally Patient Root - FIND) SOP Classes will be 
supported. Refer to the DICOM Standard (DICOM 1999 PS 3.4) for detailed descriptive 
semantics. 

6.14.4.1.1 Trigger Events 

The user at the Image Display wishes to view selected images. 

6.14.4.1.2 Message Semantics 

The message semantics are defined by the DICOM Query/Retrieve SOP Classes. 

A C-FIND Request from the DICOM Study Root Query/Retrieve Information Model - FIND 
SOP Class or optionally the DICOM Patient Root Query/Retrieve Information Model - FIND 
SOP Class shall be sent from the Image Display to the Image Archive. Hierarchical Search 
Method shall be supported. 

The Image Display uses one or more matching keys as search criteria to obtain the list of 
matching entries in the Image Archive at the selected level (Patient & Study/Series/Image). 
Based on this list of entries, the Image Display may select relevant entries to be retrieved. 

The matching keys and return keys to be supported by the Image Display (SCU) and the Image 
Manager (SCP) are defined in the table below. The table specifies for both the Query SCU 
(Image Display) and the Query SCP (Image Archive) if Matching Keys (keys used as matching 
criteria in the Query request) and Returned Keys (Keys used to request attributes to be returned 
in the query responses) are Required (R) or Optional (O). See section 2.2 for more information. 

Table 6.14-1 below includes the definition of return and matching keys specified by DICOM. 
Requirements indicated with R+ highlight the requirements added by the IHE Technical 
Framework. 
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Table 6.14-1. Images Query Matching and Return Keys 


Attributes Name 

Tag 

Query Keys Matching 

Query Keys Return 

Notes 

SCU 

SCP 

SCU 

SCP 

Study Level 

Study Date 

(0008,0020) 

R+ 

R 

R+ 

R 


Study Time 

(0008,0030) 

R+ 

R 

R+ 

R 


Accession Number 

(0008,0050) 

R+ 

R 

R+ 

R 


Patient Name 

(0010,0010) 

R+ 

R 

R+ 

R 

IHE- 1 , IHE-2 

Patient ID 

(0010,0020) 

R+ 

R 

R+ 

R 


Study ID 

(0020,0010) 

R+ 

R 

R+ 

R 


Study Instance UID 

(0020.000D) 

R+ 

R 

O 

R 


Modalities in Study 

(0008,0061) 

R+ 

R+ 

R+ 

R+ 


Referring 
Physician's Name 

(0008,0090) 

R+ 

R+ 

R+ 

R+ 

IHE-l.IHE-2 

Study Description 

(0008,1030) 

O 

O 

O 

O 


Procedure Code 
Sequence 

(0008,1032) 

O 

O 

O 

O 


>Code Value 

(0008,0100) 

O 

O 

O 

O 


>Coding Scheme 
Designator 

(0008,0102) 

O 

O 

O 

O 


>Coding Scheme 
Version 

(0008,0103) 

O 

O 

O 

O 


>Code Meaning 

(0008,0104) 

O 

O 

O 

O 


Name of 

Physician(s) Reading 
Study 

(0008,1060) 

O 

O 

O 

O 

IHE- 1 , IHE-2 

Admitting Diagnoses 
Description 

(0008,1080) 

O 

O 

O 

O 


Referenced Study 
Sequence 

(0008,1110) 

O 

O 

O 

O 


>Referenced SOP 
Class UID 

(0008,1150) 

O 

O 

O 

o 


>Referenced SOP 
Instance UID 

(0008,1155) 

O 

o 

O 

o 


Referenced Patient 
Sequence 

(0008,1120) 

O 

o 

O 

0 


>Referenced SOP 
Class UID 

(0008,1150) 

O 

o 

O 

o 


>Referenced SOP 
Instance UID 

(0008,1155) 

O 

o 

O 

0 


Referenced SOP 
Instance UID 

(0008,1155) 

O 

o 

O 

0 


Patient’s Birth Date 

(0010,0030) 

O 

o 

R+ 

R+ 


Patient's Birth Time 

(0010,0032) 

O 

o 

O 

O 


Patient’s Sex 

(0010,0040) 

O 

o 

R+ 

R+ 
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Other Patient IDs 

(0010,1000) 

O 

O 

O 

O 


Other Patient Names 

(0010,1001) 

0 

O 

O 

O 

IHE-1, IHE-2 

Patient’s Age 

(0010,1010) 

o 

O 

O 

O 


Patient’s Size 

(0010,1020) 

0 

O 

O 

O 


Patient’s Weight 

(0010,1030) 

o 

O 

O 

O 


Ethnic Group 

(0010,2160) 

o 

O 

O 

O 


Occupation 

(0010,2180) 

0 

O 

O 

O 


Additional Patient 
History 

(0010,21B0) 

o 

O 

O 

O 


Patient Comments 

(0010,4000) 

o 

O 

O 

O 


Other Study 
Numbers 

(0020,1070) 

0 

O 

O 

O 


Number of Patient 
Related Studies 

(0020,1200) 

N/A 

N/A 

O 

O 


Number of Patient 
Related Series 

(0020,1202) 

N/A 

N/A 

O 

O 


Number of Patient 
Related Instances 

(0020,1204) 

N/A 

N/A 

O 

O 


Number of Study 
Related Series 

(0020,1206) 

N/A 

N/A 

O 

R+ 


Number of Study 
Related Instances 

(0020,1208) 

N/A 

N/A 

O 

R+ 


Interpretation Author 

(4008,0100 

O 

O 

O 

O 

IHE- 1 , IHE-2 

Series Level 

Modality 

(0008,0060) 

R+ 

R 

R+ 

R 


Series Number 

(0020,0011) 

R+ 

R 

R+ 

R 


Series Instance UID 

(0020, 000E) 

R+ 

R 

O 

R 


Number of Series 
Related Instances 

(0020,1209) 

N/A 

N/A 

O 

R 


Performed Procedure 
Step ID 

(0040, 0253) 

O 

O 

O 

O 


Reference Study 

Component 

Sequence 

(0008,1111) 

O 

O 

O 

O 


>Referenced SOP 
Class UID 

(0008,1150) 

o 

o 

O 

O 


>Referenced SOP 
Instance UID 

(0008,1155) 

o 

o 

O 

O 


Request Attribute 
Sequence 

(0040,0275) 

R+ A 

R+ A 

R+ A 

R+ A 

IHE-3 

>Requested 
Procedure ID 

(0040,1001) 

R+ 

R+ 

R+ 

R+ 


>Scheduled 
Procedure Step ID 

(0040,0009) 

R+ 

R+ 

R+ 

R+ 


Performed Procedure 
Step Start Date 

(0040,0244) 

R + 

R+ 

R+ 

R+ 
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Performed Procedure 
Step Start Time 

(0040,0245) 

R + 

R+ 

R+ 

R+ 


Composite Object Instance Level 

Instance Number 

(0020,0013) 

R 

R 

O 

R 


Overlay Number 

(0020,0022) 

O 

O 

O 

O 


Curve Number 

(0020,0024) 

O 

O 

O 

O 


LUT Number 

(0020,0026) 

O 

O 

O 

O 


SOP Instance UID 

(0008,0018) 

R+ 

R 

O 

R 


SOP Class UID 

(0008,0016) 

O 

R 

O 

R+ 

IHE-4 


Note: A = optional for IHE Technical Framework : Year 2 but required for Year 3. 
The table below extends the table above with image-specific keys. 


Table 6.14-2. Image Specific Query Matching and Return Keys 


Attribute Name 

Tag 

Query Keys Matching 

Query Keys Return 

Notes 

SCU 

SCP 

SCU 

SCP 

Image Specific Level 

Rows 

(0020 0010) 

o 

o 

0 

R+ 


Columns 

(0020,0011) 

o 

o 

0 

R+ 


Bits Allocated 

(0028,0100) 

0 

o 

0 

R+ 


Number of Frames 

(0028,0008) 

o 

0 

o 

R+ 



IHE-1: Case insensitive matching is allowed in the IHE Technical Framework: Year 2, 

for attributes of VR PN. A DICOM Change Proposal (CP 190) to allow case 
insensitivity on PN attributes is currently pending. 

IHE-2: SCUs are recommended to append wildcard at the end of each component of 

any structured name to facilitate matching (i.e., PN attributes). 

IHE-3: Universal Matching (selecting return keys) against an Attribute of VR SQ should 

be requested by the Query SCU using a Zero Length Sequence Attribute. Query SCPs 
shall accept such Universal Match Requests. In addition. Query SCPs are required by 
the DICOM Standard to support requests for a Universal Match for an SQ attribute 
encoded as a zero length item. 

IHE-4: A SOP Class UID is a non-ambiguous key to identify a specific type of image 

(Modality is not). 

6.14.4.1.3 Expected Actions 

The Image Archive receives the C-FIND request, performs the matching on the provided keys 
and sends the list of matching records back to the Image Display via C-FIND responses. It is the 
responsibility of the Image Manager to assure that the patient and procedure information is 
current in the images when they are retrieved from the Image Archive. The patient and procedure 
information is updated through Transactions 12 and 13. 
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6.15 Query Presentation State 

This section corresponds to Transaction 15 of the IHE Technical Framework: Year 2. 
Transaction 15 is required for the Image Archive Actor and is optional for the Image Display 
Actor. 

6.15.1 Scope 

This section describes the sequence of messages required for the Image Display to query the 
Image Archive for instances of Grayscale Softcopy Presentation States. The Image Display will 
query and then retrieve Presentation State objects together with the image data referenced in the 
return keys supplied in the response from the Image Archive. The transformations will be 
applied by the Image Display to the image data to assure the image display is consistent with the 
device that originally created and stored the Presentation State. The Image Display will be 
required to support all transformations defined in DICOM Supplement 33: Grayscale Softcopy 
Presentation State Storage. In addition, multiple Presentation States may exist that reference the 
same image data. 

6.15.2 Use Case Roles 



Actor: Image Display 

Role: Query for Grayscale Softcopy Presentation State objects together with the referenced 
image data and apply the transformations specified by the Presentation State. This actor must 
support pixel rendering according to the Grayscale Standard Display Function (GSDF) defined in 
DICOM 1999 PS 3.14. This device will implement the Query/Retrieve SOP Classes in the role 
ofSCU. 

Actor: Image Archive 

Role: Respond to queries from the Image Display for Grayscale Softcopy Presentation States 
objects. This device will implement the Query/Retrieve SOP Classes in the role of SCP. 
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6.15.3 Referenced Standards 

DICOM 1999 PS 3.4: Query/Retrieve Service Class 

DICOM 1999 PS 3.14: Grayscale Standard Display Function 

DICOM Supplement 33: Grayscale Softcopy Presentation State Storage 

6.15.4 Interaction Diagram 


Image 

Display 


Image 

Archive 


Query Presentation States (C-FIND) 



6.15.4.1 Query for Grayscale Softcopy Presentation States 

The Query (Study Root - FIND and optionally Patient Root - FIND) SOP Classes will be 
supported. Refer to DICOM 1999 PS 3.4: Query/Retrieve Service Class for detailed descriptive 
semantics. 

6.15.4.1.1 Trigger Events 

The user of the Image Display wishes to query instances of Grayscale Softcopy Presentation 
States. 

6.15.4.1.2 Message Semantics 

The message semantics are defined by the DICOM Query/Retrieve SOP Classes. A C-FIND 
Request from the DICOM Study Root Query/Retrieve Information Model - FIND SOP Class or 
the optional DICOM Patient Root Query/Retrieve Information Model - FIND SOP Class. The 
C-FIND request shall be sent from the Image Display to the Image Archive. 

The matching keys and return keys to be supported by the Image Display (SCU) and the Image 
Archive (SCP) at the Study and Series level are defined in table 6.14-1. 

Table 6.15-1 below specifies for both the Query SCU (Image Display) and the Query SCP 
(Image Archive) additional Matching Keys (keys used as matching criteria in the Query request) 
and Return Keys (keys used to request attributes to be returned in the query responses) that are 
Required (“R”) or Optional (“O”) specific (or pertaining) to Presentation State. See section 2.2 
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for more information. 


Table 6.15-1. Presentation State Specific Query Matching and Return Keys 


Attribute Name 

Tag 

Query Keys Matching 

Query Keys Return 



SCU 

SCP 

SCU 

SCP 

Presentation Label 

(0070,0080) 

o 

o 

R+ 

R+ 

Presentation Description 

(0070,0081) 

o 

o 

O 

R+ 

Presentation Creation Date 

(0070,0082) 

o 

o 

R+ 

R+ 

Presentation Creation Time 

(0070,0083) 

o 

0 

R+ 

R+ 

Presentation Creator’s Name 

(0070,0084) 

o 

o 

R+ 

R+ 

Referenced Series Sequence 

(0008,1115) 

0 

0 

R+ 

R+ 

>Series Instance UID 

(0020,000E) 

o 

o 

O 

R+ 

>Referenced Image Sequence 

(0008,1140) 

0 

0 

O 

R+ 

»Referenced SOP Class UID 

(0008,1150) 

0 

0 

O 

R+ 

»Referenced SOP Instance UID 

(0008,1155) 

0 

0 

O 

R+ 


6.15.4.1.3 Expected Actions 

The Image Archive receives the C-FIND request, performs the matching on the provided keys 
and sends the list of matching records back to the Image Display via C-FIND responses. It is the 
responsibility of the Image Manager to assure that the patient and procedure information is 
current in the images and Softcopy Presentation State objects when they are retrieved from the 
Image Archive. The patient and procedure information is updated through transactions 12 and 
13. 

6.16 Retrieve Images 

This section corresponds to Transaction 16 of the IHE Technical Framework: Year 2. 

Transaction 16 is required for the Image Archive and Image Display actors. 

6.16.1 Scope 

After the Image Display request for retrieval, the requested DICOM Images are transferred from 
the Image Archive to the Image Display for viewing. 

6.16.2 Use Case Roles 
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Actor: Image Archive: 

Role: Sends requested images to the Image Display Actor. 

Actor: Image Display 

Role: Receives requested images from the Image Archive Actor. 

6.16.3 Referenced Standards 

DICOM 1999 PS 3.4: Storage Service Class 
DICOM 1999 PS 3.4: Query/Retrieve Service Class 

6.16.4 Interaction Diagram 

Image Manager Image 

Display 



6.16.4.1 Retrieve Images 

The Retrieve (Study Root - MOVE and optionally Patient Root - MOVE) SOP Classes will be 
supported. The DICOM Image Storage SOP Classes will be supported by the Image Archive as 
an SCP. Refer to DICOM 1999 (Part PS 3.4, Annex C, for detailed descriptive semantics. 

6.16.4.1.1 Trigger Events 

Images are selected for viewing at the Image Display. 

6.16.4.1.2 Message Semantics 

The message semantics are defined by the DICOM Query/Retrieve SOP Classes and the DICOM 
Image Storage SOP Classes. 

A C-MOVE Request from the DICOM Study Root Query/Retrieve Information Model - MOVE 
SOP Class or the DICOM Patient Root Query/Retrieve Information Model - MOVE SOP Class 
shall be sent from the Image Display to the Image Archive. 
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6.16.4.1.3 Expected Actions 

The Image Archive receives the C-MOVE request, establishes a DICOM association with the 
Image Display and uses the appropriate DICOM Image Storage SOP Classes to transfer the 
requested images. The Image Display is expected to support at least one of the SOP Classes 
specified in table 6.8-1. It is assumed that support of retrieval for a SOP Class also means 
support for display. 

6.16.4.2 View Images 

This transaction relates to the “View Images” event of the above interaction diagram. 

6.16.4.2.1 Trigger Events 

The Image Display is requested to display the images. 

6.16.4.2.2 Invocation Semantics 

This is a local invocation of functions at the Image Display, and the method used by the Image 
Display to interpret and display the image data in a meaningful way is outside the scope of the 
IHE Technical Framework. If the DICOM image is referenced by other DICOM composite 
objects, such as Grayscale Softcopy Presentation States, it is optional for the Image Display to 
actually retrieve and display/apply these objects. 

6.16.4.2.3 Expected Actions 

The Image Display presents to the user a DICOM Image. 

6.17 Retrieve Presentation States 

This section corresponds to Transaction 17 of the IHE Technical Framework: Year 2. 
Transaction 17 is required for the Image Archive Actor and optional for the Image Display 
Actor. 

6.17.1 Scope 

This section describes the sequence of messages required for the Image Display to retrieve 
Grayscale Softcopy Presentation State Instances from the Image Archive. The Image Display 
will query and then retrieve Presentation State objects together with the image data referenced in 
the return keys supplied in the response from the Image Archive. The transformations will be 
applied by the Image Display to the image data to assure the image display is consistent with the 
device that originally created and stored the Presentation State. The Image Display will be 
required to support all transformations defined in DICOM Supplement 33: Grayscale Softcopy 
Presentation State Storage. In addition, multiple Presentation States may exist that reference the 
same image data. 
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6.17.2 Use Case Roles 



Actor: Image Display 

Role: Retrieve Grayscale Softcopy Presentation State objects together with the referenced image 
data and apply the transformations specified by the Presentation State. This actor must support 
pixel rendering according to the Grayscale Standard Display Function (GSDF) defined in 
DICOM 1999 PS 3.14. This device will implement the Query/Retrieve SOP Classes in the role 
of an SCU. 

Actor: Image Archive 

Role: Respond to retrieve requests from the Image Display for Grayscale Softcopy Presentation 
States objects. Transmit requested Grayscale Softcopy Presentation State object(s) to the Image 
Display. This device will implement the Query/Retrieve SOP Classes in the role of an SCP. 

6.17.3 Referenced Standards 

DICOM 1999 PS 3.4: Query/Retrieve Service Class 

DICOM 1999 PS 3.14: Grayscale Standard Display Function 

DICOM Supplement 33: Grayscale Softcopy Presentation State Storage 


Rev. 4.0 
03-28-2000 


127 


Copyright © 2000: HIMSS/RSNA 




IHE Technical Framework: Year 2 


6.17.4 Interaction Diagram 


Image Image 

Display Archive 


Select Presentation States (C-MOVE) 


Store Presentation States (C-STORE) 


View Presentation States 


6.17.4.1 Retrieve Grayscale Softcopy Presentation State 

This transaction refers to the “C-MOVE” and “C-STORE” messages between the Image Display 
and Image Archive in the above interaction diagram. The Retrieve (Study Root - MOVE and 
optionally Patient Root - MOVE) SOP Classes will be supported. Refer to the DICOM Standard 
(DICOM 1999 PS 3.4) for detailed descriptive semantics. 

6.17.4.1.1 Trigger Events 

The Image Display selects specific Grayscale Softcopy Presentation State objects to retrieve 
from the Image Archive. 

6.17.4.1.2 Message Semantics 

The message semantics are defined in the DICOM Query/Retrieve Service Class section of the 
DICOM 1999 PS 3.4: Query/Retrieve Service Class. It is the responsibility of the Image 
Manager to assure that the patient and procedure information is current in the images and 
Softcopy Presentation State objects when they are retrieved from the Image Archive. 

6.17.4.1.3 Expected Actions 

The Image Archive receives the C-MOVE request, establishes a DICOM association with the 
Image Display, and uses the DICOM Grayscale Softcopy Presentation State Storage SOP Class 
to transfer the requested Presentation State objects. 
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6.17.4.2 View Presentation States 

This transaction relates to the “View Presentation States” event in the above interaction diagram. 
Presentation States cannot be viewed by themselves but must be applied to an image. Refer to 
section 6.16 for a description of the transaction used to retrieve images to which Presentation 
States may be applied. 

6.17.4.2.1 Trigger Events 

The Image Display receives Presentation State instances from the Image Archive 

6.17.4.2.2 Invocation Semantics 

This is a local invocation of functions resident within the Image Display. The method used by 
the Image Display to present images for viewing by the user after the Presentation State 
transformations have been applied is outside the scope of the IHE Technical Framework. 

6.17.4.2.3 Expected Actions 

The Image Display applies the transferred Grayscale Softcopy Presentation State to image data 
and renders it for viewing. 

6.18 Creator Images Stored 

This section corresponds to Transaction 18 of the IHE Technical Framework: Year 2. 

Transaction 18 is required for the Image Archive Actor and optional for the Image Creator Actor. 
However, the Image Creator Actor is required to support either Transaction 18 or Transaction 19, 
and may support both. 

6.18.1 Scope 

In the Creator Images Stored transaction, the Image Creator sends the newly generated images 
for a study to the Image Archive. 

6.18.2 Use Case Roles 



Actor: Image Creator 
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Role: Transmit generated image data to Image Archive. 
Actor: Image Archive 

Role: Accept and store images from Image Creators. 

6.18.3 Referenced Standards 

DICOM 1999 PS 3.4: Storage Service Class. 

6.18.4 Interaction Diagram 


Image Image 

Creator Archive 



6.18.4.1 Images Stored 

6.18.4.1.1 Trigger Events 

The Image Creator can transfer images to the Image Archive sequentially within one or more 
DICOM associations, as the images become available or collectively. 

6.18.4.1.2 Message Semantics 

The Image Creator uses the DICOM C-STORE message to transfer the images. The Image 
Creator is the DICOM Storage SCU and the Image Archive is the DICOM Storage SCP. 

Per the DICOM Standard the Image Creator shall create a new series for its created images and 
not extend series containing source images. 

The Image Creator derives images from source images, and the derived images may or may not 
have the same Image SOP Class as the source images. 

The source images may include Performed Procedure Step relationship information. This 
information will include Scheduled Procedure Step information for the procedure performed at 
an Acquisition Modality. When present in the source images, the Image Creator shall extract 
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appropriate Scheduled Procedure Step information and include it with PPS information produced 
by the Image Creator. 

See appendix C for rules on how to use the source image information in the derived image 
objects. 

6.18.4.1.3 Expected Actions 

The Image Archive will store the received DICOM objects. 

6.19 Creator Presentation State Stored 

This section corresponds to Transaction 19 of the IHE Technical Framework: Year 2. 

Transaction 19 is required for the Image Archive Actor and optional for the Image Creator Actor. 
However, the Image Creator Actor is required to support either Transaction 18 or Transaction 19, 
and may support both. 

6.19.1 Scope 

This section describes DICOM Grayscale Softcopy Presentation States Storage requests issued 
by the Image Creator to the Image Archive. The Image Creator sends Presentation States for 
storage along with the images so they could be later used for support of consistent display of 
imaging data. The Image Creator will be the DICOM Store SCU and the Image Archive will be 
the DICOM Store SCP. DICOM Supplement 33: Grayscale Softcopy Presentation State Storage 
defines the transformations supported by this transaction. 

6.19.2 Use Case Roles 



Actor: Image Creator 

Role: Generate image data and Grayscale Softcopy Presentation State objects for storage to the 
Image Archive. This actor must support pixel rendering according to the Grayscale Standard 
Display Function as defined in DICOM 1999 PS 3.14. 

Actor: Image Archive 
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Role: Accept and store Grayscale Softcopy Presentation State Instances received from the 
Image Creator. This transaction describes the role related only to storage of the Presentation 
State information. 

6.19.3 Referenced Standards 

DICOM 1999 PS 3.4: Storage Service Class 

DICOM Supplement 33: Grayscale Softcopy Presentation State Storage 
DICOM 1999 PS 3.14: Grayscale Standard Display Function 

6.19.4 Interaction Diagram 

Image Image 

Creator Archive 



6.19.4.1 Creator Presentation State Stored 

6.19.4.1.1 Trigger Events 

The Image Creator generates a Grayscale Softcopy Presentation State Instance and sends it to the 
Image Archive for storage. 

6.19.4.1.2 Message Semantics 

The Image Creator uses the DICOM C-STORE message to store Grayscale Softcopy 
Presentation States. Message semantics are defined in the Grayscale Softcopy Presentation State 
Storage SOP Class behavior section of the DICOM Standard (DICOM Supplement 33). 

The Image Creator derives images from source images that may include Modality Performed 
Procedure Step relationship information. This information will include Scheduled Procedure 
Step information for the procedure performed at an Acquisition Modality. When present in the 
source images, the Image Creator shall extract appropriate Scheduled Procedure Step 
information and include it with PPS information produced by the Image Creator. 

6.19.4.1.3 Expected Actions 

The Image Archive will store the received Grayscale Softcopy Presentation State objects. 
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6.20 Creator Procedure Step In Progress 

This section corresponds to Transaction 20 of the IHE Technical Framework: Year 2. 
Transaction 20 is required for the Department System Scheduler/Order Filler, Image Manager 
and Performed Procedure Step Manager actors. It is optional for the Image Creator actor. 

6.20.1 Scope 

This Performed Procedure Step of the Image Creator will be appended to the Modality 
Performed Procedure Steps done at the Acquisition Modality for the same Scheduled Procedure 
Step. It includes a message from the Image Creator to the Performed Procedure Step Manager, 
which in turn issues the messages to the Department System Scheduler/Order Filler and the 
Image Manager. The Performed Procedure Step Manager must support forwarding messages to 
two different destinations. It shall start issuing messages to the configured destinations 
immediately after it accepts the corresponding messages from the Image Creator. 

For the details on the Performed Procedure Step Manager refer to section 6.6.1. 

6.20.2 Use Case Roles 



Actor: Department System Scheduler/Order Filler. 

Role: Receives the PPS information forwarded by the Performed Procedure Step Manager. 
Actor: Image Manager. 

Role: Receives the PPS information forwarded by the Performed Procedure Step Manager. 
Actor: Image Creator. 

Role: Informs the Performed Procedure Step Manager that a particular Performed Procedure 
Step has started. 

Actor: Performed Procedure Step Manager. 

Role: Accepts Performed Procedure Step information from an Image Creator and transmits it to 
the Department System Scheduler/Order Filler and Image manager. 
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6.20.3 Referenced Standards 

DICOM 1999 PS 3.4: Modality Performed Procedure Step SOP Class. 

6.20.4 Interaction Diagram 


Image 

Creator 


Performed Department System 

Procedure Step Scheduler/Order 

Manager Filler 


Image 

Manager 



6.20.4.1 Procedure Step Started Message 

6.20.4.1.1 Trigger Event 

Technologist begins with the generation of images at the Image Creator station. 

6.20.4.1.2 Message Semantics 

The Image Creator uses the Modality Performed Procedure Step SOP Class (N-CREATE 
Service) to inform the Performed Procedure Step Manager that a specific image generation 
Procedure Step has been started and is in progress. In turn, the Performed Procedure Step 
Manager uses the N-CREATE Service to forward the information to the Department System 
Scheduler/Order Filler and Image Manager. The Performed Procedure Step Manager shall use 
the same Performed Procedure Step SOP Instance UID during this interchange. The following 
aspects shall be taken into the account during implementation of this step. 

6.20.4.1.2.1 Patient/Procedure/Procedure Step Information 

The Image Creator shall ensure that the Patient/Procedure/Procedure Step information it has is 
valid and current. In this case the identification and relationship information will not be 
provided by a Modality Worklist, but the Image Creator extracts the Scheduled Procedure Step 
information from the images it uses as originals. If those images satisfied several Scheduled 
Procedure Steps, information about all of them may be recorded in the resulting PPS messages 
and image headers. 
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6.20.4.1.2.2 Required Attributes 

Appendix C lists a number of attributes that have to be properly handled by the Image Creator to 
ensure consistency between Performed Procedure Step object attributes and information included 
into the generated images. 

6.20.4.1.2.3 Relationship between Scheduled and Performed Procedure Steps 

In this case the Scheduled Procedure Step is specified in the relationship part of the MPPS 
information in the source images. Therefore we have the Append Case relationship between 
Scheduled and Performed Steps. Refer to appendix C for details of forming attributes (Study 
Instance UID, Procedure ID, Accession Number, etc.) in this case. 

6.20.4.1.2.3.1 Append Case 



This is a special case of 1-to-N relationship between SPS and PPS where first the PPS is 
generated at the Acquisition Modality in response to an SPS. The new Performed Procedure 
Steps is added at the Image Creator at a later time. The Performed Procedure Steps will refer 
back to the same Requested Procedure and to the original SPS. All Requested Procedure and 
Scheduled Procedure Step attributes contained in the source images shall be copied to the 
Performed Procedure Step Relationship Module (see appendix C). 

6.20.4.1.3 Expected Actions 

The DSS/Order filler receives information from the Performed Procedure Step Manager and 
links it with the Requested Procedure. If the Requested Procedure ID is transmitted empty, the 
Department System Scheduler/Order Filler and the Image Manager will create an exception that 
must be manually resolved to link the Performed Procedure Step to the appropriate procedure. 


6.21 Creator Procedure Step Completed 

This section corresponds to Transaction 21 of the IHE Technical Framework: Year 2. 
Transaction 21 is required for the Department System Scheduler/Order Filler, Image Manager 
and Performed Procedure Step Manager actors. It is optional for the Image Creator actor. 
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6.21.1 Scope 

This transaction includes a message from the Image Creator to the Performed Procedure Step 
Manager, which in turn issues the messages to the DSS/Order Filler and the Image Manager that 
the Performed Procedure Step has been completed. Information is not being released for billing 
at this point but a code may be assigned. The Image Manager may need the information to co- 
locate images of the same study. The Performed Procedure Step Completed message does not 
necessarily mean that the set of images is complete or available for retrieval. 

6.21.2 Use Case Roles 



Actor: Departmental System Scheduler/Order Filler. 

Role: Receives the PPS information forwarded by the Performed Procedure Step Manager. 
Actor: Image Manager. 

Role: Receives the PPS information forwarded by the Performed Procedure Step Manager. 
Actor: Image Creator. 

Role: Informs the Performed Procedure Step Manager that a particular Performed Procedure 
Step is completed. 

Actor: Performed Procedure Step Manager. 

Role: Accepts Performed Procedure Step information from an Image Creator and transmits it to 
the Department System Scheduler/Order Filler and the Image Manager. 

6.21.3 Referenced Standards 

DICOM 1999 PS 3.4: Modality Performed Procedure Step SOP Class. 
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6.21.4 Interaction Diagram 
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Note: The diagram above shows the sequencing of messages for the Performed Procedure Step 
SOP Class. Image Creators will also implement the Storage and Storage Commitment classes. 
The timing relationship between MPPS messages and Storage and Storage Commitment 
messages is not specified. That is, MPPS messages may occur before or after storage requests. 

6.21.4.1 Procedure Step Completed/Discontinued 

6.21.4.1.1 Trigger Event 

Technologist completes the procedure step from the Image Creator station. 

6.21.4.1.2 Message Semantics 

The Image Creator uses the Modality Performed Procedure Step SOP Class (N-SET Service) to 
inform the Performed Procedure Step Manager that a specific Procedure Step has been 
completed or discontinued. For further details on the message semantics refer to section 
6.7.4. 1.2. 

The Image Creator derives images from source images that include Performed Procedure Step 
information. This information will include scheduled step information for the procedure 
performed at an Acquisition Modality. When present in the source images, the Image Creator 
shall extract appropriate PPS information and include it with the PPS messages and the images 
produced by the Image Creator. 

6.21.4.1.3 Expected Actions 

The Image Manager and Department System Scheduler/Order Filler receive information about 
the Procedure Step being completed or discontinued. The Image Manager and Department 
System Scheduler/Order Filler are not required to act on intermediate N-SET messages with the 
PPS Status "IN PROGRESS". 
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6.22 Creator Storage Commitment 

This section corresponds to Transaction 22 of the IHE Technical Framework: Year 2. 

Transaction 22 is required for the Image Manager and Image Creator actors. 

6.22.1 Scope 

In the Creator Images Stored and/or the Creator Presentation States Stored transaction the Image 
Creator has sent the generated images and/or Presentation States of a study to the Image Archive. 
In this Creator Storage Commitment transaction the Image Creator requests that the Image 
Manager/Image Archive accept responsibility for the images and/or Presentation States. The 
objective of this transaction is to provide a formal release of storage responsibility by the Image 
Creator, allowing it to reuse its internal resources allocated to the study. 

6.22.2 Use Case Roles 



Actor: Image Creator 

Role: Make requests for storage commitment to the Image Manager for the images and/or 
Presentation States previously transmitted. 

Actor: Image Manager. 

Role: Assume responsibility for reliable storage, retrieval, and validity of image data and 
Presentation States. 

6.22.3 Referenced Standards 

DICOM 1999 PS 3.4: Storage Commitment Push Model SOP Class. 
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6.22.4 Interaction Diagram 
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6.22.4.1 Images Committed 

The Storage Commitment Push Model SOP Class shall be used as reflected in the interaction 
diagram. The Storage Commitment Pull Model SOP Class will not be supported. Refer to the 
DICOM 1999 PS 3.4 for detailed descriptive semantics. 

6.22.4.1.1 Trigger Events 

The Image Creator is the Storage Commitment SCU and can issue a commitment request at any 
time after the successful transfer of one or more SOP Instances to the Image Manager, which is 
the Storage Commitment SCP. 

6.22.4.1.2 Message Semantics 

Refer to Section 6.10.4.1.2 for the semantics of this message (with Image Creator in place of 
Acquisition Modality). 

6.22.4.1.3 Expected Actions 

The Image Manager in coordination with the Image Archive accepts responsibility for the safe 
storage of the transferred image data and/or Presentation States. (The form of the cooperation is 
beyond the scope of IHE Technical Framework.) Ownership of data transfers from the Image 
Creator to the Image Manager. The Image Creator is then free to manage its own internal 
resources accordingly. 
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6.23 Print Request with Presentation LUT 

This section corresponds to Transaction 23 of the IHE Technical Framework: Year 2. 

Transaction 23 is required for the Print Composer and Print Server actors. 

6.23.1 Scope 

This transaction supports the capability of the Print Composer to ensure display consistency for 
images rendered by the Print Server. The Print Composer sends a DICOM Print Request to the 
Print Server. The request includes the specification of a Presentation Look Up Table (LUT) to 
be applied to the image data at the Film Box level. The Print Composer will be the DICOM Print 
SCU and the Print Server will be the DICOM Print SCP. 

6.23.2 Use Case Roles 



Actor: Print Composer 

Role: Generate DICOM Print Requests as a DICOM Print SCU. The system must support pixel 
rendering according to the DICOM Grayscale Standard Display Function (GSDF) as defined in 
DICOM 1999 PS 3.14. The Print Requests must specify and reference Presentation LUTs to be 
applied by the SCP to the image data to maintain desired image perception. 

Actor: Print Server 

Role: Process DICOM Print Requests as a DICOM Print SCP. The system must support pixel 
rendering according to the DICOM Grayscale Standard Display Function (GSDF) as defined in 
DICOM 1999 PS 3.14 and be able to transform the image data using the specified Presentation 
LUT to produce the desired image perception. 

6.23.3 Referenced Standards 

DICOM 1999 PS 3.4: Print Management Service Class 
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DICOM 1999 PS 3.4: Presentation LUT SOP Class 
DICOM 1999 PS 3.14: Grayscale Standard Display Function 

6.23.4 Interaction Diagram 
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6.23.4.1 DICOM Film Session N-CREATE 

Support of this message is required for the Print Composer and Print Server in the IHE Technical 
Framework: Year 2. The Film Session N-CREATE message describes the presentation 
parameters common to all sheets of film in a film session. Implementation of this message will 
be according to the DICOM Basic Print Management Meta SOP Class. 


Rev. 4.0 
03-28-2000 


141 


Copyright © 2000: HIMSS/RSNA 






IHE Technical Framework: Year 2 


6.23.4.1.1 Trigger Events 

The Print Composer initiates a Print Request to the Print Server. 

6.23.4.1.2 Message Semantics 

The message semantics are defined by the DICOM Print Management Service Class Behavior 
for the Basic Film Session SOP Class. 

6.23.4.1.3 Expected Actions 

The Print Server shall create the Film Session SOP Instance and initialize attributes as specified 
in the N-CREATE. The Print Server shall return the status code of the requested SOP Instance 
creation as defined for the Basic Film Session SOP Class. 

6.23.4.2 DICOM Presentation LUT N-CREATE 

Support of this message is required by the Print Composer and Print Server in the IHE Technical 
Framework: Year 2. The Presentation FUT data specified by this N-CREATE will be used to 
transform the image data at the film box level to realize specific image display characteristics 
suitable to the Print Composer. In addition, this message can use the Presentation FUT Shape 
Attribute to specify a pre-defined Presentation FUT Shape (The Presentation FUT Shape value 
of “FIN OD” will not be supported for the IHE Technical Framework: Year 2). Presentation 
FUT information will only be specified and applied at the Film Box level for the IHE Technical 
Framework: Year 2. 

6.23.4.2.1 Trigger Events 

This message will be triggered when the Print Composer receives a successful status response 
from the Print Server following transmission of the Film Session N-CREATE message. 

6.23.4.2.2 Message Semantics 

The message semantics are defined by the DICOM Print Management Service Class Behavior 
for the Presentation FUT SOP Class. Presentation FUTs supplied by the Print Composer will be 
required to have a number of entries corresponding to the bit depth of the image data (e.g. 256 
entries for 8 bit image data, 4096 entries for 12 bit image data). 

6.23.4.2.3 Expected Actions 

The Print Server shall create a Presentation FUT SOP Instance and initialize attributes as 
specified in the N-CREATE. The Print Server shall return the status code of the requested SOP 
Instance creation as defined for the Presentation FUT SOP Class. 
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6.23.4.3 DICOM Film Box N-CREATE 

Support of this message is required by the Print Composer and Print Server in the IHE Technical 
Framework: Year 2. The Film Box N-CREATE message describes the presentation parameters 
common to a single sheet of film in a film session. 

6.23.4.3.1 Trigger Events 

This message will be triggered when the Print Composer receives a successful status response 
from the Print Server following transmission of the Presentation LUT N-CREATE message. 

6.23.4.3.2 Message Semantics 

The message semantics are defined by the DICOM Print Management Service Class Behavior 
for the Basic Film Box SOP Class. A Film Box N-CREATE will be issued for each sheet of film 
in a multi-film session. The Print Composer, behaving as a DICOM Print SCU, may use default 
values for Illumination(2010,015E), Reflective Ambient Light (2010,0160), Min 
Density(2010,0120), and Max Density(20 10,0 130) as specified in DICOM 1999 PS 3.14. In 
addition, the Film Box N-CREATE message will reference Presentation LUT SOP instances 
created by the Presentation LUT N-CREATE message. Table 6.23-1 below specifies the Basic 
Film Box Attribute values required to be supported by the SCU. 


Table 6.23-1. Film Box Module Attributes Supported by the Print Composer 


Tag 

Attribute Name 

Supported Values 

(2010,0010) 

Image Display Format 

STAND ARD\C,R 
(C = columns, R = rows) 

(2010,0040) 

Film Orientation 

PORTRAIT 

LANDSCAPE 

(2010,0050) 

Film Size ID 

8INX10IN 
1 1INX14IN 
14INX17IN 

(2010,0060) 

Magnification Type 

REPLICATE 

BILINEAR 

CUBIC 

NONE 


6.23.4.3.3 Expected Actions 

The Print Server shall create the Film Box SOP Instance and initialize attributes as specified in 
the N-CREATE. The Print Server will create an Image Box SOP Instance for each image box 
defined by the Image Display Format attribute (2010,0010) at the time the Basic Film Box SOP 
Instance is created. The Print Server shall return the status code of the requested SOP Instance 
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creation as defined for the Basic Film Box SOP Class. Additional behavior is defined in the 
description of the Basic Film Box SOP Class for the DICOM Print Management Service Class 
within the DICOM Standard. 

6.23.4.4 DICOM Image Box N-SET 

Support of this message is required by Print Composer and Print Server in the IHE Technical 
Framework: Year 2. The Image Box N-SET message describes the presentation parameters and 
image pixel data specific to a single image box on a single sheet of film within a film session. 

6.23.4.4.1 Trigger Events 

This message will be triggered when the Print Composer receives a successful status response 
from the Print Server following transmission of the Film Box N-CREATE message. 

6.23.4.4.2 Message Semantics 

The message semantics are defined by the DICOM Print Management Service Class Behavior 
for the Image Box SOP Classes. An Image Box N-SET will be issued for each Image Box 
defined by the Display Format attribute (2010,0010) of the Film Box N-CREATE message. The 
Image Box N-SET message shall reference Presentation LUT SOP instances created by the 
Presentation LUT N-CREATE message. 

6.23.4.4.3 Expected Actions 

The Print Server will apply the specified image box attributes to the Image Box SOP Instance. 
The Print Server shall return the status code of the requested SOP Instance update as defined for 
the Image Box SOP Class. 

6.23.4.5 DICOM Film Box N-ACTION 

Support of this message is required by the Print Composer and Print Server in the IHE Technical 
Framework: Year 2. The Film Box N-ACTION message is used to print a single sheet of film in 
the film session. 

6.23.4.5.1 Trigger Events 

This message will be triggered when the Print Composer receives a successful status response 
from the Print Server following transmission of the last Image Box N-SET message for the 
specified Film Box. 

6.23.4.5.2 Message Semantics 

The message semantics are defined by the DICOM Print Management Service Class Behavior 
for the Film Box SOP Classes. 
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6.23.4.5.3 Expected Actions 

The sheet of film described by the film box is printed by the Print Server. Presentation LUT 
SOP Instances referenced at the Film Box or Image Box levels will be applied to the image data. 
The Print Server shall return the appropriate status code as defined for the Film Box N-ACTION 
DIMSE Service of the DICOM Print Management Service Class. 

6.23.4.6 DICOM Film Session N-ACTION 

Support of this message is optional by the Print Composer and Print Server in the IHE Technical 
Framework: Year 2. The Film Session N-ACTION message is used to print all sheets of film in 
the film session. 

6.23.4.6.1 Trigger Events 

This message will be triggered when the Print Composer receives a successful status response 
from the Print Server following transmission of the last Image Box N-SET message for the 
specified Film Session 

6.23.4.6.2 Message Semantics 

The message semantics are defined by the DICOM Print Management Service Class Behavior 
for the Film Session SOP Classes. 

6.23.4.6.3 Expected Actions 

The film session is printed by the Print Server. Presentation FUT SOP Instances referenced at the 
Film Box or Image Box levels will be applied to the image data. The Print Server shall return the 
appropriate status code as defined for the Film Session N-ACTION Service of the DICOM Print 
Management Service Class. 

6.23.4.7 Print Status (N-EVENT-REPORT) 

Support of this message is required by the Print Composer and Print Server in the IHE Technical 
Framework: Year 2. The N-EVENT-REPORT is used to report Print Server status to the Print 
Composer in an asynchronous manner. That is, a print SCP may send an N-EVENT-REPORT 
message while the SCU is transmitting additional print commands. The SCU and SCP are 
required to accommodate these asynchronous messages. 

6.23.4.7.1 Trigger Events 

This message will be triggered when the Print Server senses a change in the status related to the 
Print Request that is worthy of notification to the Print Composer . 

6.23.4.7.2 Message Semantics 

The message semantics are defined by the DICOM Print Management Service Class Behavior 
for the Printer SOP Class. 
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6.23.4.7.3 Expected Actions 

The Print Composer will return the confirmation of the N-EVENT-REPORT operation to the 
Print Server. 

6.24 Report Submission 

This section corresponds to Transaction 24 of the IHE Technical Framework: Year 2. 
Transaction 24 is required for the Report Creator and Report Manager actors. 

6.24.1 Scope 

In the Report Submission transaction, the Report Creator transmits a DICOM Structured Report 
(SR) object in an initial draft or final state to the Report Manager. 

A final report is defined as one where the Completion Flag (0040,A491) attribute is set to 
“COMPLETE” and where the Verified Flag (0040, A493) attribute is set to “VERIFIED”. 
Reports with any other values for the Completion Flag (0040,A491) or the Verified Flag 
(0040,A493) attributes are considered draft reports. 

6.24.2 Use Case Roles 



Actor: Report Creator 

Role: Transmit draft or final DICOM Structured Reports to Report Manager. 
Actor: Report Manager 

Role: Accept draft and final DICOM Structured Reports for management. 

6.24.3 Referenced Standards 

DICOM Supplement 23: Structured Reporting Storage SOP Classes (Final Text) 
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6.24.4 Interaction Diagram 
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6.24.4.1 Report Creation 

This transaction relates to the “Report Creation” event in the above interaction diagram. 

6.24.4.1.1 Trigger Events 

The user at the Report Creator wishes to create a DICOM Structured Report. 

6.24.4.1.2 Invocation Semantics 

This is a local invocation of functions at the Report Creator, and the method used by the Report 
Creator to obtain report data and create a DICOM Structured Report object is outside the scope 
of the IHE Technical Framework. The Report Creator shall create a report that conforms to the 
DICOM Basic Text SR Information Object Definition (IOD) or the DICOM Enhanced SR IOD 
if numeric values are required in the report. A single Report Creator may support both SR IODs 
if this is deemed desirable by the implementers. 

The report created by the Report Creator can be either in the draft or final state. The Report 
Creator can also create draft verified reports if necessary. An example of where a draft verified 
report may be created is on an Ultrasound machine where measurements have been taken. In this 
case, the user would verify that the measurements, as well as all other report content, are correct 
in the report created on the Ultrasound machine, but the report is not complete as no diagnosis 
has been performed. 

6.24.4.1.2.1 Coded Entries 

All Reporting actors (Report Creator, Report Manager, Report Repository, and External Report 
Repository Access) must be able to load configurable code tables. The DICOM Structured 
Report objects are dependent on coded entries to define the concepts being conveyed. The 
DICOM Committee is currently attempting to standardize commonly used codes in a license-free 
environment. In the absence of these standard codes, the IHE Committee will define such 
necessary codes for use in demonstrations. The categories of codes that will be defined, but not 
limited to, are as follows: 
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• Report Titles; 

• Report Section Headings; 

• Concept Name Codes; 

• Observation Context Codes; 

• Measurement Codes; and 

• Disposition or Conclusion Codes. 

The types of reports created by the Report Creator are defined in section 5.3.2. At a minimum, 
the Report Creator shall be able to generate reports based on the Key Image Note (section 
5.3.2. 1) and optionally the Simple Image Report (section 5. 3. 2. 2) or both. If the Report Creator 
supports the Enhanced SR Information Object Definition then it shall also support the creation of 
Simple Image and Numeric Reports (section 5. 3. 2. 3). 

6.24.4.1.2.2 Retrieve AE Title 

Whenever references to DICOM Composite objects are made within a DICOM Structured 
Report, it is possible to include the Retrieve AE Title attribute (0008,0054). In the case of the 
Report Creator, these references will be contained in the Current Requested Procedure Evidence 
Sequence attribute (0040,A375), or the Pertinent Other Evidence Sequence attribute 
(0040,A385). If the Report Creator is a standalone actor it is optional for the Retrieve AE Title 
attribute (0008,0054) to be sent and it is up to the implementation to determine what value to 
send. If the Report Creator is combined with an Image Display, then it is recommended that the 
Retrieve AE Title attribute (0008,0054) be set to the AE Title of the device from which the 
Image Display retrieved the referenced DICOM Composite objects. 

6.24.4.1.2.3 Identical Documents Sequence 

Sometimes a single report refers to multiple studies. For example, a patient involved in a 
collision may require x-rays of both the wrist and leg. These may be ordered as separate studies, 
but the Radiologist may report on both studies at the same time. To handle this situation in the 
DICOM Hierarchical Model, it is necessary to duplicate the report within each study. If a Report 
Creator is generating a single report for multiple studies, it shall create multiple copies of the 
report, with different SOP Instance UIDs for each study and use the Identical Documents 
Sequence attribute (0040,A525) in each report. The Identical Documents Sequence attribute 
(0040,A525) in each report will reference each of the other identical reports in the other studies. 
The actual content of the report, that is, the SR Document General Module attributes (except the 
Identical Documents Sequence attribute) and the SR Document Content Module attributes, will 
be the same in each report instance. 

The Retrieve AE Title attribute (0008,0054) in the Identical Documents Sequence Items shall not 
be sent. 

6.24.4.1.3 Expected Actions 

Creation of DICOM Structured Report objects ready for storage to the Report Manager. 
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6.24.4.2 Report Submission 

This transaction relates to the “DICOM C-STORE” event between the Report Creator and 
Report Manager in the above interaction diagram. 

6.24.4.2.1 Trigger Events 

When report authoring is completed and the Report Creator creates new DICOM Structured 
Reports, the Report Creator shall transfer DICOM Structured Reports to the Report Manager 
within one or more DICOM associations. 

6.24.4.2.2 Message Semantics 

The Report Creator uses the DICOM C-STORE message to transfer DICOM Structured Reports. 
The Report Creator is the DICOM Storage SCU of the Basic Text SR Storage SOP Class or the 
Enhanced SR Storage SOP Class or both. The Report Manager is the DICOM Storage SCP of at 
least the Basic Text SR Storage SOP Class and optionally the Enhanced SR Storage SOP Class. 
In accordance with the DICOM Standard for SR the Report Manager must support Level 2 (Full) 
storage, which means all DICOM Type 1, 2 and 3 attributes are stored. 

6.24.4.2.3 Expected Actions 

The Report Manager will store the received DICOM Structured Report objects. At this point the 
Report Creator relinquishes any responsibility for the report objects and may not change them in 
any way without creating a new object with a new SOP Instance UID. 
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6.25 Report Issuing 

This section corresponds to Transaction 25 of the IHE Technical Framework: Year 2. 
Transaction 25 is required for the Report Manager and Report Repository actors. 

6.25.1 Scope 

In the Report Issuing transaction, the Report Manager transmits either an unchanged draft 
DICOM Structured Report (created by a Report Creator) or a new modified DICOM Structured 
Report to the Report Repository or both. The Report Manager handles all state and content 
changes to DICOM Structured Reports and with each change new DICOM Structured Report 
objects are created and may be stored in the Report Repository. 

6.25.2 Use Case Roles 



Actor: Report Manager 

Role: Process report changes and transmit reports to Report Repository. This involves the 
ability to handle content and state changes to DICOM Structured Reports and create new 
DICOM Structured Reports based on these changes. Examples of the types of changes the 
Report Manager needs to process are as follows: 

• Verifying a draft report and setting the verification attributes in the newly created verified 
report; 

• Creating a new unverified report based on one or more previous draft or verified reports; 

• Creating a new verified report based on one or more previous draft or verified reports; 
and 

• Creating a new report that is the result of merging multiple previous reports. 

Actor: Report Repository 

Role: Accept and store DICOM Structured Reports from Report Managers. 

6.25.3 Referenced Standards 

DICOM Supplement 23: Structured Reporting Storage SOP Classes (Final Text) 
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6.25.4 Interaction Diagram 


Report Report 

Manager Repository 



6.25.4.1 Report Issuing (Step 1) 

This transaction relates to the top “DICOM C-STORE” event between the Report Manager and 
Report Repository in the above interaction diagram. 

6.25.4.1.1 Trigger Events 

When DICOM Structured Reports are received from the Report Creator, the Report Manager can 
transfer the DICOM Structured Reports to the Report Repository within one or more DICOM 
associations. This capability should be configurable as it may enable access to reports before 
they are verified and finalized. Some sites may require this feature, while others may find it 
undesirable. 

6.25.4.1.2 Message Semantics 

The Report Manager uses the DICOM C-STORE message to transfer DICOM Structured 
Reports. The Report Manager is the DICOM Storage SCU of at least the Basic Text SR Storage 
SOP Class and optionally the Enhanced SR Storage SOP Class. It is required that if a Report 
Manager is an SCP of the Enhanced SR Storage SOP Class (see section 6.24) then it shall also be 
an SCU of the Enhanced SR Storage SOP Class. The Report Repository is the DICOM Storage 
SCP of both the Basic Text SR Storage SOP Class and the Enhanced SR Storage SOP Class. In 
accordance with the DICOM Standard for SR, the Report Repository must support Level 2 (Full) 
storage, which means all DICOM Type 1, 2 and 3 attributes are stored. 

6.25.4.1.3 Expected Actions 

The Report Repository will store the received DICOM Structured Report objects. 


Rev. 4.0 
03-28-2000 


151 


Copyright © 2000: HIMSS/RSNA 





IHE Technical Framework: Year 2 


6.25.4.2 Report Modification 

This transaction relates to the “Report Modification or Verification” event in the above 
interaction diagram. 

6.25.4.2.1 Trigger Events 

The user at the Report Manager selects an existing report and decides to make some modification 
to this report. 

6.25.4.2.2 Invocation Semantics 

This is a local invocation of functions at the Report Manager, and the method used by the Report 
Manager to specify report state transitions or obtain modified report data and create a new 
DICOM Structured Report object is outside the scope of the IHE Technical Framework. The 
Report Manager shall create a report that conforms to the DICOM Basic Text SR Information 
Object Definition or the DICOM Enhanced SR Information Object Definition if numeric values 
are to be included in the report either by their addition by the Report Manager or numeric values 
appeared in the original report received from the Report Creator. It is required that if a Report 
Manager can receive Enhanced SR objects, that it can also manage such objects and generate 
new Enhanced SR objects. If the Report Manager removes numeric values from a report it may 
convert an Enhanced SR object into a Basic Text SR object. When the Report Manager creates a 
new modified report it must be in a different series to the original report, unless the Report 
Manager and Report Creator are the same device. This is because the DICOM Standard requires 
that objects created by different devices must be in different series (i.e., different DICOM 
General Equipment Module attributes). In order to reference the original report, the new 
modified report must correctly contain the Predecessor Documents Sequence attribute 
(0040, A3 60). 

The types of external state changes the Report Manager shall handle are: 

• completing a partial report; and 

• verifying a report. 

To complete a partial report, additional content may be added to the original report and the 
Completion Flag attribute (0040,A491) shall be set to “COMPLETE”. To verify a report, the 
content of the original report is checked for correctness, and the Verification Flag attribute 
(0040,A493) shall be set to “VERIFIED”. This also requires that the Verifying Observer 
Sequence attribute (0040,A073) is completed appropriately. 

The types of reports that at a minimum shall be handled by the Report Manager are defined in 
section 5.3.2. The Report Manager shall be able to manipulate reports based on the Key Image 
Note (section 5.3.2. 1) and the Simple Image Report (section 5. 3. 2. 2). If the Report Manager 
supports the Enhanced SR Information Object Definition then it shall also support manipulation 
of Simple Image and Numeric Reports (section 5. 3. 2. 3). Even though the IHE Technical 
Framework sets boundaries on the complexity of SR objects, the Report Manager must still be 
able to receive and store any Basic Text SR object and optionally any Enhanced SR object in 
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order to conform to the DICOM Standard. An implementation may restrict the modification 
capabilities for reports more complex than those specified in section 5.3.2. 

There are many reasons and methods for the Report Manager to modify the content of a report 
and these are outside the scope of the IHE Technical Framework. Examples of the types of 
changes, in addition to the state changes above, that the Report Manager needs to be able to 
process are as follows: 

• Creating a new report based on one or more previous draft or verified reports where data 
is changed or added; 

• Creating a new report that is the result of merging multiple previous reports. This can 
also involve changing or adding report data; and 

• Converting a Basic Text SR into an Enhanced SR if the Report Manager adds 
measurements. This also means that if a Basic Text SR is merged with an Enhanced SR 
then the resulting object will be an Enhanced SR. 

It is recommended that amendments to DICOM Structured Reports are made by creating a new 
DICOM Structured Report object containing the original content as well as any amendments or 
additions. References to the original report are made by the Predecessor Document Sequence 
attribute (0040,A360). 

6.25.4.2.2.1 Retrieve AE Title 

Whenever references to DICOM Composite objects are made within a DICOM Structured 
Report, it is possible to include the Retrieve AE Title attribute (0008,0054). In the case of the 
Report Manager, these references will be contained in the Predecessor Documents Sequence 
attribute (0040, A360), as well as the Current Requested Procedure Evidence Sequence attribute 
(0040,A375) and the Pertinent Other Evidence Sequence attribute (0040,A385) if these evidence 
sequence attributes are used by the Report Creator. 

The Report Creator may send reports to the Report Manager where the Retrieve AE Title 
attribute (0008,0054) in the Current Requested Procedure Evidence Sequence Items 
(0040,A375), or the Pertinent Other Evidence Sequence Items (0040,A385) is empty or not sent. 
In these cases the Report Manager may add the AE Title of a configured Image Manager in the 
Retrieve AE Title attribute (0008,0054) of these sequence items. 

When the Report Manager creates a new report based on one or more previous reports that it has 
already stored in the Report Repository, then the AE Title of the Report Repository shall be used 
as the Retrieve AE Title attribute (0008,0054) in the Predecessor Documents Sequence Items 
(0040,A360). If the prior reports have not been stored in the Report Repository then the Retrieve 
AE Title attribute (0008,0054) shall not be sent. 

6.25.4.2.2.2 Identical Documents Sequence 

When the Report Manager is modifying a report that contains items in the Identical Documents 
Sequence attribute (0040, A5 25) then a decision is needed as to the actions to occur upon the 
other identical documents. The user modifying the report should be asked as to whether the 
changes should only apply to the current report or to the other identical documents as well. If the 
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changes are limited to one report, then no Identical Documents Sequence attribute (0040,A525) 
shall be included in the new report as it is no longer the same as the other documents. If the 
changes are to apply to multiple reports, then multiple new reports with new SOP Instance UIDs 
shall be created with the new report data and their Identical Documents Sequence attribute 
(0040,A525) shall refer to the appropriate new report objects. Also in this case each Predecessor 
Documents Sequence attribute (0040,A360) shall refer to all the original identical documents. 
This is shown in figure 6.25-1. 



Figure 6.25-1. Identical and Predecessor Document Sequences 

6.25.4.2.3 Expected Actions 

Creation of a new modified DICOM Structured Report object ready for storage to the Report 
Repository. 

6.25.4.3 Report Issuing (Step 2) 

This transaction relates to the bottom “DICOM C-STORE” event between the Report Manager 
and Report Repository in the above interaction diagram. 

6.25.4.3.1 Trigger Events 

When reports are finalized (complete and verified) they shall be stored in the Report Repository. 
The Report Manager can transfer DICOM Structured Reports to the Report Repository within 
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one or more DICOM associations. Internal reports shall be temporarily stored in the Report 
Manager until they are finalized, but may also be stored permanently in the Report Repository if 
the Report Manager decides to transfer them. The technique used by the Report Manager to 
finalize a report is outside the scope of the IHE Technical Framework. 

6.25.4.3.2 Message Semantics 

The Report Manager uses the DICOM C-STORE message to transfer DICOM Structured 
Reports. The Report Manager is the DICOM Storage SCU of at least the Basic Text SR Storage 
SOP Class and optionally the Enhanced SR Storage SOP Class. It is required that if a Report 
Manager is an SCP of the Enhanced SR Storage SOP Class (see section 6.24) then it shall also be 
an SCU of the Enhanced SR Storage SOP Class. The Report Repository is the DICOM Storage 
SCP of both the Basic Text SR Storage SOP Class and the Enhanced SR Storage SOP Class. In 
accordance with the DICOM Standard for SR the Report Repository must support Level 2 (Full) 
storage, which means all DICOM Type 1, 2 and 3 attributes are stored. 

6.25.4.3.3 Expected Actions 

The Report Repository will store the received DICOM Structured Report objects. 
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6.26 Query Report 

This section corresponds to Transaction 26 of the IHE Technical Framework: Year 2. 
Transaction 26 is required for the Report Repository, Report Reader, and External Report 
Repository Access actors. 

6.26.1 Scope 

In the Query Report Transaction, the Report Reader queries the Report Repository or External 
Report Repository Access for draft or final DICOM Structured Reports. 

6.26.2 Use Case Roles 



Actor: Report Repository 

Role: Responds to queries for DICOM Structured Reports. 

Actor: External Report Repository Access 

Role: Responds to queries for DICOM Structured Reports. This system provides storage of 
DICOM Structured Reports obtained from outside the Radiology department. Such a system may 
be required to convert reports of different formats (HL7) into DICOM Structured Reports (see 
appendix E). 

Actor: Report Reader 

Role: Queries Report Repository or External Report Repository Access for DICOM Structured 
Reports and makes them available for selection. 

6.26.3 Referenced Standards 

DICOM 1999 PS 3.4: Query/Retrieve Service Class 

DICOM Supplement 23: Structured Reporting Storage SOP Classes (Final Text) 
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6.26.4 Interaction Diagram 


Report 

Repository 


Report 

Reader 


External Report 
Repository 
Access 



6.26.4.1 Query Reports 

This transaction relates to the query section of the above interaction diagram. The Query (Study 
Root - FIND and optionally Patient Root - FIND) SOP Classes will be supported. Refer to 
DICOM 1999 PS 3.4: Query/Retrieve Service Class for detailed descriptive semantics. 

6.26.4.1.1 Trigger Events 

The user at the Report Reader wishes to view selected reports. 

6.26.4.1.2 Message Semantics 

The message semantics are defined by the DICOM Query/Retrieve SOP Classes. 

A C-FIND Request from the DICOM Study Root Query/Retrieve Information Model - FIND 
SOP Class or the DICOM Patient Root Query/Retrieve Information Model - FIND SOP Class 
shall be sent from the Report Reader to the Report Repository or External Report Repository 
Access. 

The Report Reader uses one or more matching keys as search criteria to obtain the list of 
matching entries in the Report Repository or External Report Repository Access at the selected 
level (Patient & Study/Series/Instance). 

In addition to the required and unique keys defined by the DICOM Standard, the IHE Technical 
Framework has defined matching and return keys to be supported by query SCU and SCPs. The 
keys are defined in section 6.14.4.1.2 and table 6.14-1 while the conventions for key usage are 
defined in section 2.2. For the Report Reader (SCU) and the Report Repository and External 
Report Repository Access (SCP) the additional SR Instance specific keys are defined in table 
6.26-1. 
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Table 6.26-1. SR Instance Specific Query Matching and Return Keys 


Attribute Name 

Tag 

Query Keys Matching 

Query Keys Return 

SCU 

SCP 

SCU 

SCP 

SR Instance Specific Level 

Completion Flag 

(0040.A491) 

R+ 

R+ 

R+ 

R+ 

Verification Flag 

(0040, A493) 

R+ 

R+ 

R+ 

R+ 

Content Date 

(0008,0023) 

O 

O 

O 

R+ 

Content Time 

(0008,0033) 

O 

O 

O 

R+ 

Observation DateTime 

(0040, A032) 

o 

o 

o 

R+ 

Verifying Observer Sequence 

(0040, A073) 

R+ 

R+ 

R+ 

R+ 

> Verifying Organization 

(0040, A027) 

O 

O 

R+ 

R+ 

> Verification DateTime 

(0040,A030) 

R+ 

R+ 

R+ 

R+ 

>Verifying Observer Name 

(0040,A075) 

R+ 

R+ 

R+ 

R+ 

> Verifying Observer 
Identification Code Sequence 

(0040,A088) 

O 

O 

R+ 

R+ 

Referenced Request Sequence 

(0040,A370) 

O 

O 

R+ 

R+ 

>Study Instance UID 

(0020,000D) 

O 

O 

R+* 

R+ 

>Accession Number 

(0008,0050) 

O 

O 

R+ 

R+ 

>Requested Procedure ID 

(0040,1000) 

O 

O 

R+ 

R+ 

>Requested Procedure Code 
Sequence 

(0032,1064) 

O 

O 

O 

R+ 

»Code Value 

(0008,0100) 

O 

O 

O 

R+ 

»Coding Scheme Designator 

(0008,0102) 

O 

O 

O 

R+ 

»Coding Scheme Version 

(0008,0103) 

O 

O 

O 

R+ 

»Code Meaning 

(0008,0104) 

O 

O 

O 

R+ 

Concept Name Code Sequence 

(0040, A043) 

R+ 

R+ 

R+ 

R+ 

>Code Value 

(0008,0100) 

R+ 

R+ 

R+ 

R+ 

>Coding Scheme Designator 

(0008,0102) 

R+ 

R+ 

R+ 

R+ 

>Coding Scheme Version 

(0008,0103) 

O 

O 

O 

R+ 

>Code Meaning 

(0008,0104) 

O 

O 

R+ 

R+ 


6.26.4.1.3 Expected Actions 

The Report Repository or External Report Repository Access receives the C-FIND request, 
performs the matching on the provided keys and sends the list of matching records back to the 
Report Reader via C-FIND responses. 

6.27 Retrieve Reports 

This section corresponds to Transaction 27 of the IHE Technical Framework: Year 2. 
Transaction 27 is required for the Report Repository, Report Reader, and External Report 
Repository Access actors. 
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6.27.1 Scope 

In the Retrieve Report Transaction, the requested DICOM Structured Reports are transferred 
from the Report Repository or External Report Repository Access to the Report Reader for 
viewing. 

6.27.2 Use Case Roles 



Actor: Report Repository 

Role: Sends requested DICOM Structured Reports to Report Reader. 

Actor: External Report Repository Access 

Role: Sends requested DICOM Structured Reports to Report Reader. Such a system may be 
required to convert reports of different formats (HL7) into DICOM Structured Reports (see 
appendix E). 

Actor: Report Reader 

Role: Retrieves DICOM Structured Reports from Report Repository or External Report 
Repository Access and makes them available for viewing. 

6.27.3 Referenced Standards 

DICOM 1999 PS 3.4: Query/Retrieve Service Class 

DICOM Supplement 23: Structured Reporting Storage SOP Classes (Final Text) 
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6.27.4 Interaction Diagram 

Report Report External Report 

Repository Reader Repository 

Access 

I I I 

I I I 

I I I 



I I I 

I I I 

6.27.4.1 Retrieve Reports 

This transaction relates to the retrieve section of the above interaction diagram. The Retrieve 
(Study Root - MOVE and optionally Patient Root - MOVE) SOP Classes will be supported. The 
DICOM Basic Text SR Storage SOP Class and optionally the DICOM Enhanced SR Storage 
SOP Class will be supported by the Report Reader as an SCP. Both the DICOM Basic Text SR 
Storage SOP Class and the DICOM Enhanced SR Storage SOP Class will be supported by the 
Report Repository as an SCU. The DICOM Basic Text SR Storage SOP Class and optionally the 
DICOM Enhanced SR Storage SOP Class will be supported by the External Report Repository 
Access as an SCU. Refer to the DICOM Standard (PS 3.4, Annex C, and Supplement 23) for 
detailed descriptive semantics. 

6.27.4.1.1 Trigger Events 

The user at the Report Reader selects specific reports to view. 

6.27.4.1.2 Message Semantics 

The message semantics are defined by the DICOM Query/Retrieve SOP Classes and the DICOM 
Structured Report Storage SOP Classes. 
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A C-MOVE Request from the DICOM Study Root Query/Retrieve Information Model - MOVE 
SOP Class or the DICOM Patient Root Query/Retrieve Information Model - MOVE SOP Class 
shall be sent from the Report Reader to the Report Repository or External Report Repository 
Access. 

6.27.4.1.3 Expected Actions 

The Report Repository or External Report Repository Access receives the C-MOVE request, 
establishes a DICOM association with the Report Reader and uses the appropriate DICOM 
Structured Report Storage SOP Classes (Basic Text SR Storage SOP Class and/or Enhanced SR 
Storage SOP Class) to transfer the requested reports. 

6.27.4.2 View Reports 

This transaction relates to the “View Reports” event of the above interaction diagram. 

6.27.4.2.1 Trigger Events 

The Report Reader receives reports from the Report Repository or External Report Repository 
Access. 

6.27.4.2.2 Invocation Semantics 

This is a local invocation of functions at the Report Reader, and the method used by the Report 
Reader to interpret and display the report data in a meaningful way is outside the scope of the 
IHE Technical Framework. At a minimum the Report Reader shall be able to correctly display 
reports defined in section 5.3.2. The Report Reader shall be able to display reports based on the 
Key Image Note (section 5.3.2. 1) and the Simple Image Report (section 5. 3. 2. 2). If the Report 
Reader supports the Enhanced SR Information Object Definition then it shall also support 
display of Simple Image and Numeric Reports (section 5. 3. 2. 3). Even though the IHE Technical 
Framework sets boundaries on the complexity of SR objects, the Report Reader must still be able 
to receive, store and view any Basic Text SR object and optionally any Enhanced SR object in 
order to conform to the DICOM Standard. An implementation may not be able to render, in a 
meaningful way, reports more complex than those specified in section 5.3.2. 

If a DICOM Structured Report references other DICOM composite objects, such as images, and 
softcopy presentation states, it is optional for the Report Reader to actually retrieve and 
display/apply these objects, but the Report Reader must convey to the user that such references 
exists in the report. 

6.27.4.2.2.1 Retrieve AE Title 

If the Report Reader is grouped with an Image Display and capable of retrieving objects 
referenced in a DICOM Structured Report then the Report Reader should retrieve these objects 
from the device matching the appropriate Retrieve AE Title attribute (0008,0054) included in the 
DICOM Structured Report. If the Retrieve AE Title attribute is not specified or configured, then 
the Report Reader should use some other configurable Retrieve AE Title. 
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6.27.4.2.3 Expected Actions 

The Report Reader presents to the user a DICOM Structured Report. 
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Appendix A: Clarification of Accession Number and Requested 

Procedure ID 

The purpose of this appendix is to clarify the entity relationship and role of the Accession 
Number and the Requested Procedure ID. 

A.1: Definition of Accession Number 

The Accession Number attribute is defined in the DICOM Imaging Service Request Entity. The 
IHE Framework has chosen to equate the DICOM Imaging Service Request and the HL7 Filler 
Order Entities. A subset of the IHE Integrated Data Model Entity Relationship (ER) and keys 
are as follows: 


Departmental link to the 
order entry system: 


Intradepartmental 
information (e.g., reporting, 
charging, etc.): 


Procedure scheduling and 
acquisition definition level: 



Figure A.1-1. Subset of IHE Data Model 
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In the healthcare industry today, the term Accession Number (or Requisition Number) is used 
inconsistently to refer either to a collection of Requested Procedures (a Filler Order) or to a 
single Requested Procedure. In the IHE model defined above, the Accession Number is a 
collector of Requested Procedures and thus of reports as well as imaging studies. 

Institutions that use Accession Number in the role of Requested Procedure ID face problems 
managing complex procedures involving multiple modalities since they must rely on a simplified 
data model (1-to-l: Imaging Service Request contains just one procedure). In the IHE model, the 
Accession Number can reference multiple Requested Procedures. It follows also that in the IHE 
model the Accession Number can contain multiple Study Instance UIDs. 

The IHE Framework views the relationship of the Accession Number as the user-friendly 
representation of the Filler Order Number, and the Requested Procedure ID as the user-friendly 
representation of the Study Instance UID within an institution. 

The specific correlation between the Accession Number and Filler Order Number, as well as the 
correlation between the Requested Procedure ID and the Study Instance UID, is an 
implementation matter that is left to each system. 

The relationship of the Accession Number and the Requested Procedure ID can be enumerated as 
follows: 


Case 1 (Simple Case): 

Accession Number : Requested Procedure ID is 1:1. 



An example of case 1 is an order of an “MR head” which results in a single Requested 
Procedure. A single report may be generated for the order. 

Case 2: 

Accession Number : Requested Procedure ID is 1:1 - Requested Procedure level is expanded 
with modalities integrated with departmental information system via MWL. 



An example of case 2 is an order of “cardiac stress” which results in a multimodality Requested 
Procedure (recall that Modality is specified at the Scheduled Procedure Step level). The “cardiac 
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stress” Requested Procedure may result in a NM and a MR Scheduled Procedure Step. Both the 
MR study and the NM study should have the same Accession Number, Requested Procedure ID, 
and Study Instance UID. A single report is generated for the order. 

Another example of case 2 is an order for a “Nuclear stress” which results in two separate 
acquisitions on the nuclear system, separated by six hours in time. Again, both image 
acquisitions would ideally have the same Accession Number, Requested Procedure ID, and 
Study Instance UID. A single report may be generated for the order. 

Case 3: 

Accession Number : Requested Procedure ID is 1:1 - Requested Procedure level is expanded, 
but modality does not have MWL resulting in a l:n relationship 



An example of case 3 would be the same “cardiac stress” resulting in a multimodality Requested 
Procedure, but in a department where the modalities have not implemented MWL (and therefore 
do not receive the Accession Number, Requested Procedure ID, nor Study Instance UID from the 
departmental information system). Because the image acquisitions have different Study Instance 
UIDs at the Requested Procedure level, the acquisitions are effectively grouped at the Filler 
Order/Imaging Service Request level. If both acquisition devices are able to incorporate the 
Requested Procedure ID, a single report may be generated. If two different Requested Procedure 
IDs are also used, then two reports may be generated. 

Note that MWL is a required transaction of the IHE Technical Framework; this example is given 
for illustrative purposes. 

Case 4: 

Accession Number : Requested Procedure ID is l:n - An Accession Number/Filler Order 
generates n Requested Procedures 



An example of case 4 would be the same “cardiac stress” as above, but where the departmental 
information system creates several Requested Procedures, one for each modality. In this 
example, the image studies will be assigned the same Accession Number, but different 
Requested Procedure IDs and Study Instance UIDs. In this case, separate reports may be 
generated for each Requested Procedure. 
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Another example of case 4 would be a simple broken arm case. In this example, the Filler Order 
could be "radiology study of the arm". The Requested Procedure could be "X-ray study - right 
arm". The Scheduled Procedure Step could be "A/P and lateral of the right arm". Typically, 
there is a follow up radiology exam performed six weeks after the broken arm incident. This 
follow up study, if ordered along with the initial study, could have the same Accession Number 
as the previous study, but a new Requested Procedure ID, new Study Instance UID, and a new 
Scheduled Procedure Step ID. 

A.2: Impact on Current Implementations 

In the DICOM Model, the departmental information system, which is usually acting as the 
DICOM Modality Worklist SCP, creates the following keys (not a comprehensive list): 

• Accession Number - Filler Order/Imaging Service Request level 

• Study Instance UID - Requested Procedure level 

• Requested Procedure ID - Requested Procedure level 

• Scheduled Procedure Step ID - Scheduled Procedure Step level 

The departmental information system that does not support multiple Requested Procedures per 
Filler Order has the option to manage the Accession Number : Requested Procedure ID 
relationship as 1:1. In this case, the implementation of the Requested Procedure ID may be as 
simple as copying the currently implemented Accession Number into the DICOM Requested 
Procedure ID field on the fly during the creation of the MWF response. 

Alternatively, the departmental information system has the flexibility to create the Accession 
Number : Requested Procedure ID relationship as l:n. An example of this would be a Filler 
Order that requires both a Nuclear Medicine and an MR acquisition as part of the same “study”. 
In this case, both acquisitions will be scheduled as separate Scheduled Procedure Steps of the 
same procedure and should be provided the same information for Accession Number, Study 
Instance UID, and Requested Procedure ID keys as part of the MWF response. If, however, 
either the NM or MR acquisition devices has not implemented MWF SCU, (and assuming there 
is a user interface field on the scanners to input Accession Number) the departmental information 
system can still link these two seemingly separate acquisitions with different Study Instance 
UIDs using the Accession Number. Note that MWF is a required transaction of the IHE 
Technical Framework; this example is given for illustrative purposes. 

A.3: User Education 

The radiology user community first has to be educated on the five levels of the ER model as used 
by IHE, and the key identifiers for each of those levels. If this can be expressed in such a way 
that the users understand the difference between Accession Number and Requested Procedure 
ID, an evolution in terminology will have to take place at institutions where the term “Accession 
Number” is currently used at the Requested Procedure level. 
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The MWL implementer community will have to be educated on the usage of the key identifiers 
and why it is important to use and retain the correct information at the correct levels. This may 
include both database as well as user interface changes. 

Key points to be illustrated are that the Requested Procedure ID is more important on an 
acquisition system/scanner than is the Accession Number. 

A.4: Rationale 

The following items were unanimously agreed upon: 

• There are five ER levels necessary for IHE: Patient, Placer Order, Filler Order, Requested 
Procedure, and Scheduled Procedure Step/Modality Performed Procedure Step 

• The Requested Procedure entity tracks from scheduling through interpretation 

• The Requested Procedure level is the “charging” and “reporting” level 

• The Filler Order Number and the Study Instance UID are not user friendly and not 
intended for GUI display (are intended for computers to use) 

• The Accession Number is a user-visible number on the Department System Scheduler 
There were two options: 

1. Map Accession Number to Requested Procedure ID at the Requested Procedure Level 

2. Map Accession Number to Filler Order Number 

Benefits of option 1 : 

• Requested Procedure ID is easier to map to DICOM Accession Number (note that Filler 
Order number is comprised of 4 components in HL7). 

• The user interface at the modalities may not have to change. 

Benefits of option 2: 

• There would be no changes to the DICOM Standard. Changing the entity relationship of 
the Accession Number to the Study Instance UID would require a new MWL SOP class 
in DICOM and could potentially negate the current momentum behind the MWL 
implementations in the field. 

• There are systems in place with data using the l:n relationship between Accession 
Number: Study Instance UID. This would be nearly impossible to re-map. 

• There are modalities which do not support MWL and therefore effectively implement the 
l:n relationship between Accession: Study Instance UID (i.e., the modalities still generate 
their own Study Instance UID). 

• Requested Procedure ID is a “clean” field without connotation in the field today. 

Conclusion: 

Both options 1 and 2 have the drawbacks of having to educate the user and development 
community on the refined usage of Accession Number. The arguments for option 2 were deemed 
stronger and this option was selected for the reasons defined above. 
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Appendix B: Topics for Standards Corrections or Supplements 

B.1: HL7 Topics 

The IHE Technical Framework: year 2 defines a ZDS Segment as a temporary solution for 
handling Study Instance UID. A request has been sent to the IMSIG of HL7 for considering an 
extension of the HL7 standard, which may make its way into version beyond 2.3.1. 

B.2: DICOM Topics 

A change Proposal, CP 191, was accepted by DICOM Working group 6 at the March, 2000 
meeting to allow the C-FIND SCP to support the Image Availability data element (0008, 0056) 
to indicate the relative time of retrieval. The value of this tag will be set to ONFINE if 
corresponding images are in the immediately available storage (cache, RAID), NEARFINE, if 
images are located in a longer-term storage (CD jukebox, for example), and OFFFINE, if images 
has to be retrieved from the media not currently in the system (i.e., CD or tape not currently 
mounted in the jukebox/tape library). 

Correction proposal CP 190 has also been accepted byWG6 to support case-insensitive matching 
for DICOM elements of VR PN in C-FIND requests. This will allow patient names, for example, 
to be matched without regard to their case. 

Both correction proposals mentioned above, though accepted by WG6, need to be balloted by the 
full DICOM Committee. 
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Appendix C: Attribute Consistency between Modality Worklist, 

Composite lODs and Modality Performed Procedure 
Step 

This appendix is an integral part of the IHE Technical Framework. It reflects IHE’s adoption of 

Annex M of Part 4 (PS3.4) of the DICOM Standard. It includes three sections: 

• The first section contains the summary table of PS3.4 Annex M and its notes with IHE 
clarifications. IHE requires that the Attribute mapping defined in this table be supported 
by Modality Actors as they implement MWL, various IOD Storage and PPS SOP Classes 
for Transactions 6, 7, 20 and 21. A number of IHE notes have been added to this DICOM 
Table (IHE-x) to restate some of the DICOM Annex M requirements as well as select 
some of the choices offered or enforce some of the recommendations of DICOM. A few 
additional IHE recommendations are also specified. 

• The second section extends this table with additional IHE Requirements based on a 
number of critical attributes (Type 2 in DICOM) common to most composite instances 
(Images, Standalone and GSPS IODs). 

• The third section introduces a real-world data model of the entities and their Attributes 
related to consistency. Readers are advised to use this data model along with the table 
presented in section 4. This data model is provided only for ease of understanding and 
does not introduce any additional IHE requirements. 

C.1 : Integration-critical Attributes 

The table below shall be interpreted as follows: 

• An Attribute shown in the first column, shall be requested by a MWL SCU (Acquisition 
Modality) as a return key in its C-FIND Requests. Attribute Values shall be returned in 
the Modality Worklist C-FIND response by the Department System Scheduler. 

• The return Attribute Values shall be used by the Acquisition Modality in filling the 
Attribute shown on the corresponding line of table C- 1 both for Composite Instances 
(second column) and MPPS Instances. 

• The PPS Manager, Image Manager and Department System Scheduler roles shall be 
capable of handling the Attributes shown in the corresponding line of the third column as 
defined by the SCP Type and the additional notes. 

• Mappings which are critical to maintaining the relationship between information objects 
distributed among IHE Actors have been highlighted with a bolded border. Non Bolded 
Attributes are not critical to maintaining relationships between objects, but are 
nonetheless important from an information distribution point of view. 

• IHE requirements specified in IHE notes extend or clarify DICOM requirements (e.g. 
TYPE 3 Attributes are required under specific circumstances; DICOM recommendations 
are mandated). 
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Table C-1. Comparison of Corresponding Attributes of Modality Worklist Information 
Model, Image and Standalone lODs and Modality Performed Procedure Step IOD 


Modality Worklist [Return 
Key Type] (e) (IHE-9) 

Images and Standalone 
IOD[Type] 

MPPS IOD [SCU/SCP Type] 



Scheduled Step Attributes Sequence 
[1/1] (c) 

Study Instance UID [1] 

Study Instance UID [1] (IHE-1) 

>Study Instance UID [1/1] (IHE-2) 
(IHE-20) 

Referenced Study Sequence [2] (d) 

Referenced Study Sequence [3] (c) 
(IHE- 18) 

Referenced Study Sequence [2/2] (f) 
(IHE-3) 

Accession Number [2] (IHE- 13) 

Accession Number [2] (IHE-7) 

Recession Number [2/2] (IHE-4) 

.... 

Request Attributes Sequence [3] (a,c) 
(IHE-1 1) 

.... 

Requested Procedure ID [1] ] (IHE- 
13) 

>Requested Procedure ID [1C] 

Requested Procedure ID [2/2] 

Scheduled Procedure Step ID [1] 
(IHE- 14) 

>Scheduled Procedure Step ID [1C] 

>Scheduled Procedure Step ID [2/2] 

Scheduled Procedure Step Description 
[1C] (IHE- 15) 

>Scheduled Procedure Step 
Description [3] 

>Scheduled Procedure Step 
Description [2/2] 

Scheduled Action Item Code 
Sequence [1C] (IHE- 15) 

>Scheduled Action Item Code 
Sequence [3] 

— 

— 

Performed Action Item Code 
Sequence [3] (IHE-10) (IHE-19) 

Performed Action Item Code 
Sequence [2/2] (IHE-10) 

.... 

Study ID [2] (IHE-5) 

Study ID [2/2] 

.... 

Performed Procedure Step ID [3] (b) 

Performed Procedure Step ID [1/1] 

.... 

Performed Procedure Step Start Date 
[3] (b) (IHE-8) 

Performed Procedure Step Start Date 
[1/1] 

.... 

Performed Procedure Step Start Time 
[3] (b) (IHE-8) 

Performed Procedure Step Start Time 
[1/1] 

.... 

Performed Procedure Step Description 
[3] (IHE-8) 

Performed Procedure Step Description 
[2/2] 

Requested Procedure Description [1C] 
(IHE- 16) 



Requested Procedure Code Sequence 
[1C] (IHE- 16) 

— 

Procedure Code Sequence [2/2] (IHE- 
6) 

.... 

Referenced Study Component 
Sequence [3] (dMIHE-12) 

.... 

.... 

Referenced SOP Class UID [1C] 

SOP Class UID [1/1] 

.... 

Referenced SOP Instance UID [1C] 

SOP Instance UID [1/1] 

.... 

Protocol Name [3] (IHE-17) 

Protocol Name [1/1] 


Adapted from DICOM PS 3.4 1998, Annex M, p. 243. 
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(a) Recommended if the Modality conforms as a SCU to the Modality Worklist SOP 
Class and Modality Performed Procedure Step SOP Class 

(b) Recommended if the Modality conforms as a SCU to the Modality Performed 
Procedure Step SOP Class 

(c) Sequence may have one or more Items 

(d) Sequence may have only one Item 

(e) Worklist may have one or more Items related to one Modality Performed Procedure 
Step (IHE-9). 

(f) Referenced Study Sequence may have only one item. If more Study Sequences are 
related to the Modality Performed Procedure Step, additional Scheduled Step 
Attribute Sequence items must be created. 


(IHE-l) A Study Instance UID needs to be created by the Acquisition Modality (One of the 
options defined by PS3.4 Annex M section M.4.1) when several SPS belonging to 
different Requested Procedures are satisfied by a single PPS or when a PPS is 
unscheduled. 

(IHE-2) When a PPS is unscheduled (i.e. no SPS and Requested procedure), the Study 
Instance UID in the Scheduled Step Attribute Sequence (a single item) needs to 
contain the Study Instance UID created by the equipment for the Study Instance UID 
of the Image and stand-alone IODs it creates (See PS3.4 Annex M, section M6). 

(IHE-3) A Zero Length Referenced Study Sequence (One of the options proposed by PS3.4) 
needs to be created when a PPS is unscheduled (i.e. no SPS and Requested 
procedure). 

(IHE-4) A Zero Length Accession Number (One of the options proposed by PS3.4 Annex 
M) needs be created when a PPS is unscheduled (i.e. no SPS, Requested procedure, 
Imaging Service Request) 

(IHE-5) It is recommended to use Requested Procedure ID as Study ID in Image and stand- 
alone IODs (Unless the PPS was unscheduled or several SPS are grouped into a 
single PPS. In this case it could be equipment generated). 

(IHE-6) It is recommended to set the Procedure Code Sequence to zero length when the 
Performed Action Items differ from the Scheduled Action Item Code Sequence. 

(IHE-7) A Zero Length Accession Number (One of the options proposed by PS3.4 Annex M 
section M.4.1) shall be created when a PPS is unscheduled (i.e. no SPS, Requested 
Procedure, Imaging Service Request) or when a PPS results from several SPS 
attached to different Imaging Service Requests (i.e. different Accession Numbers). 

(IHE-8) Image and stand-alone IODs are recommended to use the values of Performed 
Procedure Step Description, Performed Procedure Step Start Date and Performed 
Procedure Step Start Time for the respective values of Study Description, Study Date 
and Study Time. 


171 


Rev. 4.0 Copyright © 2000: HIMSS/RSNA 

03-28-2000 



IHE Technical Framework: Year 2 


(IHE-9) When several Worklist Items are related to one Modality Performed Procedure Step, 
this is called by IHE the group case (Supported by DICOM PS3.4 Annex M, see Note 
(e) above). 

(IHE- 10) The Performed Action Item Code Sequence may be different from the Scheduled 
Action Item Code Sequence when it has to be changed by the image producing 
equipment operator. 

(IHE- 11) Request Attribute Sequence shall be included if the Modality conforms as a SCU to 
the Modality Worklist SOP Class and Modality Performed Procedure Step (Per 
DICOM PS3.4 Annex M recommendation, see Note (a) above), unless the 
Department System Scheduler providing Modality Worklist service was not 
accessible. 

(IHE-12) The Reference Study Component Sequence (0008,1 1 1 1) shall be included (Per 
DICOM PS3.3 section C. 7. 3. strong recommendation, General Series Module Table, 
Note 1) when Acquisition Modality Actors support MPPS. 

(IHE- 13) Accession Number and Requested Procedure ID shall be supported by Modality 

Worklist SCPs (Department System Scheduler) as matching keys. It is recommended 
that Requested Procedure IDs be assigned uniquely to identify a Requested Procedure 
within an Imaging Service Request/Filler Order which is identified by either a Filler 
Order Number or an Accession Number. 

(IHE- 14) The Scheduled Procedure Step ID values shall be assigned to at least uniquely 

identify Scheduled Procedure Steps within a Requested Procedure which is uniquely 
Identified by its Study Instance UID. 

(IHE- 15) Scheduled Procedure Step Description and Scheduled Action Item Code Sequence 
shall both be requested as Return Keys by Acquisition Modality Actors. The 
Department System Scheduler (MWL SCP) may return either one or both (Per 
DICOM Type 1C definition). 

(IHE- 16) Requested Procedure Description and Requested Procedure Code Sequence shall 
both be requested as Return Keys by Acquisition Modality Actors. The Department 
System Scheduler (MWL SCP) may return either one or both (Per DICOM Type 1C 
definition). 

(IHE- 17) It is recommended that Protocol Name be included in Composite IODs (e.g. Images 
and stand-alone IODs). 

(IHE-18) The Reference Study Sequence shall be absent (Type 3 Attribute) when a PPS is 

unscheduled (i.e. no SPS and Requested procedure), otherwise, the Sequence shall be 
present with one or more Items. Each Item shall contain the SOP Instance UID and 
the SOP Class UID of the Reference Study Sequence received in the MWL. The 
number of Items shall correspond exactly to the number of SPS grouped for a 
Performed Procedure Step. 

(IHE- 19) DICOM CP 138 states that Performed Action Item Sequence will be a type 3 

attribute in the General Series Module. The IHE Technical Framework encourages 
implementations to include this attribute which has been approved and is now 
included in the 1999 publication of the DICOM Standard. 
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(IHE-20) When several SPS belonging to different Requested Procedures are satisfied by a 
single PPS (group case), the Study Instance UID in all the items of the Scheduled 
Step Attribute Sequence needs to contain the single Study Instance UID created by 
the equipment for the Image and stand-alone IODs it creates. Note that this 
requirement is different from the suggestions described in DICOM PS3.4 Annex M, 
section M6. 

C.2: Context-critical Attributes 

This section extends the above table with additional IHE Requirements based on a number of 
context-critical attributes (Type 2 in DICOM) common to most images and standalone IODs 
when provided in response to a C-FIND Request in Return Key Attributes. The content of this 
table is strictly consistent with PS 3.4 Annex M of DICOM. 


Modality Worklist [Return 
Key Type] 

Images and Standalone IOD 
[Type] 

MPPS IOD [SCU/SCP Type] 

Patient Name [1] 

Patient Name [2] (IHE-21) 

Patient Name [2/2] (IHE-21) 

Patient ID [1] 

Patient ID [2] (IHE-21) 

Patient ID [2/2] (IHE-21) 

Patient's Birth Date [2] 

Patient's Birth Date [2] (IHE-22) 

Patient’s Birth Date [2/2] (IHE-22) 

Patient's Sex[ 2] 

Patient's Sex[ 2] (IHE-22) 

Patient's Sex[ 2/2] (IHE-22) 

Referring Physician's Name [2] 

Referring Physician's Name [2] (IHE- 
22) 

— 


IHE-21 This Attribute may be zero length when the Department System Scheduler/Order 

Filler providing the Modality Worklist service is not accessible. Pre-registered values 
for Patient ID and Patient Name will be used in the Unidentified Patient cases defined 
in the IHE Technical Framework: Year 2. 

IHE-22 This Attribute may be zero length when the Department System Scheduler/Order 

Filler providing Modality Worklist service is not accessible or the Attributes returned 
by MWF are zero length. 

C.3: Consistency Data Model 

The section introduces a data model of the entities and their Attributes related to Consistency. 
Readers are advised to use this data model along with the table presented in section 1 of 
appendix C. This data model is provided only for ease of understanding and does not introduce 
any additional IHE requirements than those specified in section C.2. 

Entities are shown by solid line rectangular boxes. 

A relationship between two entities is shown by an arrow or a straight line. In the case of 
straight lines the Attributes used to define this relationship are not described by this model (they 
are generally well understood). In the case an arrow is used: 
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The attribute in the referencing entity used to define this relationship is shown within the 
entity in a box next to the origin of the arrow (e.g. Ref. St. Seq. in the Requested 
Procedure Entity is used to link this entity with the Conceptual Study Management 
entity). 

The referenced attribute is shown at the tip of the arrow also in a rectangular box but with 
curly brackets (e.g. . . { Study Instance UID } . In some cases the referencing Attribute 


has a different name than this referenced Attribute. This reflects the way DICOM has 
elected to name and or encode those Attributes. The number shown between square 
brackets is the Data Type as defined by DICOM. 


The cardinality of relationship is defined both along straight lines and arrows: 

• Cardinality of the relationship between the entities is shown along the arrow/lines. The 
direction of the arrow has no influence on the cardinality definition. This cardinality 
reflects the cardinality between entities in a real-world data model (used as defined by 
DICOM). This cardinality may be slightly different in the DICOM Information Object 
Definition data models as this data-model reflects entity relationship supported in the 
context of information communication. For example “I-Series to I-Composite” has a 1 to 
0-n relationship to reflect that a PPS may contain a series with no Composite Instances 
(e.g. images, GSPS). However in the context of the DICOM Storage Service Class, a 
Series must contain at least one Composite Instance (e.g. image, GSPS). In other terms 
series with no images cannot be stored but can be defined by DICOM Performed 
Procedure Steps. 


Arrows with thick lines reflect the fact that the referencing Attributes are UID (broad 
uniqueness), as opposed to simple IDs which are shown by thin line arrows. 


In this Data Model, two dotted-line boxes are shown: 

• The first one groups 4 entities: I-Patient, I-Study, I-Series, I-Composite. This is intended 
to reflect the fact that Composite Instances are transferred (Storage Service Class) by 
grouping these four entities. These 4 entities are those defined by DICOM Composite 
Image Information Model (See PS 3.3, section A. 1.2) 

• The second one groups 2 entities: Requested Procedure and Conceptual Study 
Management. This reflects that those two entities are always in a one-to-one relationship. 
The Requested Procedure entity as well as those associated with it (Patient, Imaging 
Service Request, Schedule Procedure Step and Performed Procedure Step) are defined by 
the DICOM Model of the Real World for the purpose of the Modality-IS Interface (See 
PS3.3, section 7.3). The “Conceptual Study Management” entity is special in that its 
only attribute in the context of the IHE Technical Framework V3.0 is the Referenced 
SOP Instance UID (found in Reference Study Sequence). This Conceptual Study 
Detached Study entity (without the Detached Management Study SOP Class being used) 
is defined by DICOM in PS3.4 section M.2. 

Note: This Referenced SOP Instance UID cannot be assumed to have the same value as the 
Study UID in the Requested Procedure UID. Although these two entities are in a one-to-one 


Rev. 4.0 
03-28-2000 


174 


Copyright © 2000: HIMSS/RSNA 




IHE Technical Framework: Year 2 


relationship they are not constrained to use the same value of UID. This flexibility is allowed by 
the DICOM Standard and carefully preserved by the IHE Technical Framework. 



m” when multiple Scheduled Procedure Steps are satisfied 
by one Performed Procedure Step. 


Legend: 

{xxx} 

yyy 

[n] 



n-m 


: An Attribute which is a unique identifier (DICOM UID) or an identifier (DICOM ID) or for the entity 
: An Attribute which is used in the entity to reference another entity as show by the associated arrow. 

: The Attribute Type as defined by DICOM for this entity (IHE may strengthen this requirement) 

: A relationship between two entities using a unique identifier (DICOM UID) 

: A bidirectional relationship between two entities using a pair of unique identifiers (DICOM UID) 

: A relationship between two entities using a simple identifier (DICOM ID) 

: Cardinality of the relationship between the entitties, not the identifiers. (Direction of the arrow is irrelevant to cardinality.) 


Figure C-1. Data Consistency Model: Modality Worklist Information Model, Composite 
lODs and Modality Performed Procedure Step IOD 
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Appendix D: HL7 Order Mapping to DICOM MWL 

This appendix defines the mapping of the HL7 Order message (which is the ORM message as 
described in the New Order Transaction) to the DICOM Modality Worklist (which is the MWL 
DICOM Service Class as described in the Modality Worklist Transaction). Note that the ORM 
message addresses information regarding the order, not scheduling or resource management 
information. The scheduling and resource management is internal to the Department System 
Scheduler. 

Note also that this mapping does not apply to Procedure Scheduled Transaction (message from 
Department System Scheduler to Image Manager). Also see the IHE ER Model and the HL7 
Implementation Notes in section 2 for a more thorough definition of field lengths, value 
representations, and attribute types. 

Mappings between HL7 and DICOM are illustrated in the following manner: 

• Element Name (HL7 item_number. component #/ DICOM (group, element)) 

• The component value is not listed if the HL7 element does not contain multiple 
components. 


Table D-1. HL7 Order Mapping to DICOM MWL 


DICOM Description / 
Module 

DICOM Tag 

DICOM 

SCP 

Matching 

Key 

Type 

DICOM 

SCP 

Return 

Key 

Type 

HL7 

Description 

HL7 Item 
# 

HL7 

Segment 

Notes 

SOP Common 

Specific Character Set 

(0008,0005) 

O 

1C 

Principal 
Language 
of Message 

00693 

ORM 

MSH:18 


Scheduled Procedure Step 

Scheduled Procedure 
Step Sequence 

(0040,0100) 

R 

1 





>Scheduled station AE 
title 

(0040,0001) 

R 

1 




Generated by 
the department 
system 
scheduler 

>Scheduled Procedure 
Step Start Date 

(0040,0002) 

R 

1 




Generated by 
the department 
system 
scheduler 

>Scheduled Procedure 
Step Start Time 

(0040,0003) 

R 

1 




Generated by 
the department 
system 
scheduler 

>Modality 

(0008,0060) 

R 

1 




Generated by 
the department 
system 
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scheduler (note 

3) 

>Scheduled Performing 
Physician's Name 

(0040,0006) 

R 

2 

Technician 

00266 

ORM 

OBR:34 


>Scheduled Procedure 
Step Description 

(0040,0007) 

O 

1C 




Generated by 
the department 
system 
scheduler 

>Scheduled Station 
Name 

(0040,0010) 

O 

2 




Generated by 
the department 
system 
scheduler 

>Scheduled Procedure 
Step Location 

(0040,0011) 

O 

2 




Generated by 
the department 
system 
scheduler 

>Scheduled Action Item 
Code Sequence 

(0040,0008) 

O 

1C 





»Code Value 

(0008,0100) 

O 

1C 




Generated by 
the department 
system 
scheduler 

»Coding Scheme 
Designator 

(0008,0102) 

O 

1C 




Generated by 
the department 
system 
scheduler 

»Code Meaning 

(0008,0104) 

O 

3 




Generated by 
the department 
system 
scheduler 

>Pre-Medication 

(0040,0012) 

O 

2C 





>Scheduled Procedure 
Step ID 

(0040,0009) 

O 

1 

N/A 



Generated by 
the department 
system 
scheduler 

>Requested Contrast 
Agent 

(0032,1070) 

O 

2C 

N/A 



Generated by 
the department 
system 
scheduler 

>Scheduled Procedure 
Step Status 

(0040,0020) 

0 

3 

N/A 



Generated by 
the department 
system 
scheduler 

>A11 other Attributes 
from the Scheduled 
Procedure Step Module 


0 

3 





Requested Procedure 

Requested Procedure ID 

(0040,1001) 

o 

1 




Generated by 
the department 
system 
scheduler 

Requested Procedure 

(0032,1060) 

0 

1C 

Univ. Serv. 

00238.2 / 

ORM 

See note 1 
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Description 




ID/ 

Specimen 

Source 

00249.5 

OBR:4 / 

ORM 

OBR:15 


Requested Procedure 
Code Sequence 

(0032,1064) 

O 

1C 

N/A 




>Code Value 

(0008,0100) 

0 

1C 

Univ. Serv. 

ID 

00238.1 

ORM 

OBR:4 

See note 1 

>Coding Scheme 
Designator 

(0008,0102) 

o 

1C 

Univ. Serv. 

ID 

00238.3 

ORM 

OBR:4 

See note 1 

>Code Meaning 

(0008,0104) 

0 

3 

Univ. Serv. 

ID 

00238.2 

ORM 

OBR:4 

See note 1 

Study Instance UID 

(0020, 000D) 

o 

1 




Generated by 
the department 
system 
scheduler 

Referenced Study 
Sequence 

(0008,1110) 

0 

2 





>Referenced SOP Class 
UID 

(0008,1150) 

0 

1C 





>Referenced SOP 
Instance UID 

(0008,1155) 

0 

1C 





Requested Procedure 
Priority 

(0040,1003) 

0 

2 

Quantity/ 

Timing 

00221.6 

ORM 

ORC:7 

See note 2 

Patient Transport 
Arrangements 

(0040,1004) 

0 

2 

Transport 

Arrangeme 

nt 

Response. 

01031.1- 

3 

ORM 

OBR:30 


All other Attributes 
from the Requested 
Procedure Module 


0 

3 





Imaging Service Request 

Accession Number 

(0008,0050) 

0 

2 




Generated by 
the department 
system 
scheduler 

Requesting Physician 

(0032,1032) 

o 

2 

Ordering 

Provider 

00226.1- 

7 

ORM 

OBR:16 


Referring Physician's 
Name 

(0008,0090) 

0 

2 

Referring 

Doctor 

00138.1- 

7 

ORM 

PV1:8 


Placer Issuer and 
Number 

(0040,2016) 

o 

2 

Placer 
Order # 

00216.1- 

2 

ORM 

ORC:2 

See note 4 

Filler Issuer and 
Number 

(0040,2017) 

o 

2 

Filler Order 
# 

00217.1- 

2 

ORM 

ORC:3 

See note 4 

Reason for Imaging 
Service Request 

(0040,2001) 

o 

2 

Reason for 
Study 

00263 

ORM 

OBR:31 


Entered by.... 

(0040,2008) 

0 

3 

Entered 

by.... 

00224.2- 

6 

ORM 

ORC:10 


Order Entering Location 

(0040,2009) 

o 

3 

Entering 

Organizatio 

n 

00231.2 

ORM 

ORC:17 
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Order Callback Phone 
Number 

(0040,2010) 

o 

3 

Order 

Callback 

Phone 

Number 

00228 

o o 

73 73 
£ 


All other Attributes 
from the Scheduled 
Procedure Step Module 


0 

3 





Visit Identification 

Admission ID 

(0038,0010) 

o 

2 

Patient 

Account 

Number 

00121.1 

ORM 
PID: 18 

See note 6 

Issuer of Admission ID 

(0038,0011) 

o 

2 

Account 

Number 

00121.4 

ORM 
ORM 
PID: 18 

See note 6 

All other Attributes 
from the Visit 
Identification Module 


o 

3 





Visit Status 

Current Patient Location 

(0038,0300) 

o 

2 

Assigned 
Pat. Loc. 

00133 

ORM 

PV1:3 


All other Attributes 
from the Visit Status 
Module 


o 

3 





Visit Relationship 

Referenced Patient 
Sequence 

(0008,1120) 

0 

2 





>Referenced SOP Class 
UID 

(0008,1150) 

o 

2 





>Referenced SOP 
Instance UID 

(0008,1155) 

0 

2 





All other Attributes 
from the Visit 
Relationship Module 


o 

3 





Visit Admission 

All Attributes from the 
Visit Admission Module 


0 

3 





Patient Relationship 

All Attributes from the 
Patient Relationship 
Module 


0 

3 





Patient Identification 

Patient's Name 

(0010,0010) 

R 

1 

Patient 

Name 

00108 

ORM 

PID:5 


Patient ID 

(0010,0020) 

R 

1 

External 
Patient ID 

00105.1 

ORM 

PID:2 

See note 5 

Issuer of Patient ID 

(0010,0021) 

O 

3 

External 
Patient ID 

00105.4 

ORM 

PID:2 

See note 5 

Ethnic Group 

(0010,2160) 

O 

3 

Ethnic 

00125 

ORM 
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Group 


PID:22 


All other Attributes 
from the Patient 
Identification Module 


o 

3 





Patient Demographic 

Patients Birth Date 

(0010,0030) 

o 

2 

Date/ Time 
of Birth 

00110.1 

ORM 

PID:7 


Patient's Sex 

(0010.0040) 

o 

2 

Sex 

00111 

ORM 

PID:8 


Patient's Weight 

(0010,1030) 

o 

2 

Observatio 
n Value 

00573.2 
when 

00571.2 
= "Body 
Weight" 
and 

00574.2 
= "kg" 

ORM 

OBX:5 

See note 7 

Patient's Size 

(0010,1020) 

o 

2 

Observatio 
n Value 

00573.2 
when 

00571.2 
= "Body 
Height" 
and 

00574.2 
= "m" 

ORM 

OBX:5 

See note 7 

Confidentiality 
constraint on patient 
data 

(0040,3001) 

o 

2 





Region of Residence 

(0010,2152) 

0 

3 

Citizenship 

00129 

ORM 

PID:26 


Military Rank 

(0010,1080) 

0 

3 

Veterans 

Military 

Status 

00130 

ORM 

PID:27 


All other Attributes 
from the Patient 
Demographic Module 


0 

3 





Patient Medical 

Patient State 

(0038,0500) 

o 

2 

Danger 

Code 

00246 

ORM 

OBR:12 


Pregnancy Status 

(00 10,2 ICO) 

o 

2 

Ambulatory 

Status 

00145 

ORM 

PV1:15 

"B6" must be 

mapped to 

DICOM 

enumerated 

value "3" 

(definitely 

pregnant). 

Medical Alerts 

(0010,2000) 

o 

2 

Relevant 

Clinical 

Info 

00247 

ORM 

OBR:13 


Contrast Allergies 

(0010,2110) 

0 

2 

Allergy 

Code 

00205 

ADT 

AL1:3 


Special Needs 

(0038,0050) 

o 

2 
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All other Attributes 
from the Patient 
Medical Module 


O 

3 






Adapted from DICOM PS 3.4 


Notes from table D-l: 

Note 1: Universal Service ID and Specimen Source decoding: 

Universal Service ID (00238) contains six components and is decoded as described 
below. The Order Placer provides the Universal Service ID components 1-3 when it 
processes the order; the Department System Scheduler provides the Universal Service 
ID components 4-6 when it processes the order. 


The first three components of the Universal Service ID is mapped into the following 
DICOM attributes: 


• Requested Procedure Description (0032,1060) 

• Requested Procedure Code Sequence (0032,1064) 

It is important to clarify that the content of the Description attributes is free format 
text, while the content of the Code Sequence may not be altered. Also note that the 
coding schemes (e.g., CPT versus ACR, etc) are not defined by IHE but rather are 
defined by the individual institutions. Any coding schemes may be used. It is 
important to note that coding schemes must differentiate between laterality. 

Universal Service ID (00238) components shall be decoded in the following manner: 

• .1 identifier maps to Requested Procedure >Code Value (0008,0100) 

• .2 text maps to both Requested Procedure Description (0032,1060) and Requested 
Procedure >Code Meaning (0008,0104) 

• .3 name of coding scheme maps to Requested Procedure >Coding Scheme 
(0008,0102) 

Note: If laterality is not specified in the coding scheme then it is recommended to use 
Specimen Source to further clarify the free format text descriptions as follows (but 
not the Code Sequence fields, since those cannot be altered). If laterality is specified 
in the coding scheme, then use of Specimen Source is unnecessary. 

Specimen Source (00249) components shall be decoded in the following manner: 

• .5 site modifier shall be used for the L/R indicator. The L/R value shall be 
appended to the Requested Procedure Description (0032,1060). 

An example of Universal Service ID and Specimen Source decoding is: 

Universal Service ID = I23455 A XRAY OF ANKLE A CodeTMS A 5489.3 A A/P 
and lateral views of Right ANKLE A CodeXYZI 
Specimen Source = IRadiology AAAA Right A l 

Requested Procedure Description (0032,1060) = “XRAY OF ANKLE Right” 
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Requested Procedure >Code Value (0008,0100) = “23455” 

Requested Procedure >Coding Scheme (0008,0102) = “CodeTMS” 

Requested Procedure >Code Meaning (0008,0104) = “XRAY OF ANKFE” 

For the purpose of illustration, the example given above can be continued using the 
components .4-6 of the Universal Service ID if were scheduled by a system external 
to the Department System Scheduler (e.g., a Centralized Scheduling system). 

Scheduled Procedure Step Description (0040,0007) = “A/P and lateral views of 
Right ANKFE Right” 

Scheduled Action Item >Code Value(0008,0100) = “5489.3” 

Scheduled Action Item >Coding Scheme (0008,0102) = “CodeXYZ” 

Scheduled Action Item >Code Meaning (0008,0104) = “A/P and lateral views of 
Right ANKFE” 

Note 2: Only the suggested values of the HF7 Priority component of Quantity/Timing 

should be used for IHE. These values shall be mapped to the DICOM enumerated 
fields for Priority as: 


HL7 Status 

DICOM Status 

S - STAT 

STAT 

A - ASAP 

HIGH 

R - Routine 

ROUTINE 

P - Pre-op 

HIGH 

C - Callback 

HIGH 

T - Timing 

MEDIUM 


Note 3: The HF7 Diagnostic Service Section ID (00257)is being mapped directly into 

DICOM Modality, which is a defined term. The DICOM defined terms must be used 
for the MWF response as listed in DICOM PS 3.3. 

Note 4: A Change Proposal has been accepted by DICOM Working Group VI to add 

attribute (0040,2016) and (0040, 2017) to incorporate the HF7 components of Placer 
Issuer and Number, and Filler Issuer and Number. In a healthcare enterprise with 
multiple issuers of patient identifiers, both the issuer name and number are required to 
guarantee uniqueness. 

Note 5: Please refer to section 4. 1 for a more thorough discussion on the mapping of Patient 
ID and Issuer of Patient ID. 

Note 6: As described in section 4.3, the use of PID: 18 Patient Account Number alone may 
not be sufficient to uniquely identify an encounterPVl:19 Visit Number is often used 
in addition to PID_18. However, because table D-l represents a mapping to MWF, 
and because Visit information is not migrated into the C-Store composite object, it is 
assumed that the PV1:19 information will be sufficient for purposes of MWF. 
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Note 7: Patient's Weight and Patient's Size are two observations from multiple OBX 

segments. A coding scheme is not specified by IHE, but rather, the text values of 
"Body Weight" and "Body Height", respectively, are required to differentiate the two 
measurements. Note that DICOM specifies the use of "kg" and "m", respectively, for 
these measurements. An example of this HL7 encoding is: 

OBXIISTEBODY WEIGHTII A 62l A kg 
OBXIISTI A BODY HEIGHTII A 1.90l A m 

Note 8: The DICOM attribute (0038, 0050) Special Needs is listed in table D-l with no 

specific mapping from an HL7 message. In the IHE demonstration, this value is to be 
provided by the DSS/Order Filler. The prospect of mapping this attribute to an HL7 
value will be examined in the future. 
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Appendix E: Departmental Access to Non-Radiology Information 

E.1: Scope 

The access to non-radiology reports external to the imaging department is supported in the IHE 
Technical Framework by leveraging the Query Report and Retrieve Report Transactions also 
used to access imaging department Structured Reports (see sections 6.26 and 6.27). The 
External Report Repository Access provides a method to retrieve from the other department’s 
reports (e.g. Laboratory). 

The IHE Technical Framework does not restrict the manner in which this External Report 
Repository Access is implemented. It may, for example: 

• Be a Laboratory Repository System that directly supports this actor and the associated 
Query Report and Retrieve Report Transactions; 

• Accept the Query Report and Retrieve Report Transactions on one side and translate 
them into another query transaction supported by a specific laboratory report repository. 

This appendix discusses the constraints that this External Report Repository Access needs to 
support for its proper integration. 

E.2: Query Protocol 

The assumptions under which the External Report Repository Access operates are: 

1. The External Report Repository Access is responsible for formatting other department 
reports (e.g. laboratory report) into a DICOM Structured Report object (for content 
constraints see section E.3). The prime focus for the IHE Technical Framework: Year 
2 will be laboratory reports, although other department’s reports may be supported. 

2. Consistent Patient IDs will be used in the laboratory (or other) department reports and 
in the imaging department. This will ensure that a Patient ID of an image displayed by 
an Image Display, can be used as a key to retrieve recent laboratory reports for the 
same patient. This implies that the laboratory information system is integrated with the 
same ADT Patient Registration (although this integration is not within the scope of the 
IHE Technical Framework: Year 2). 

3. The Study and Series groupings are not specified by the IHE Technical Framework and 
may be arbitrarily used by the External Report Repository Access. For example, a 
DICOM Study may be created for each order (Accession Number) which contains one 
or more laboratory reports, a Series may be created for each laboratory request and so 
may contain mostly one report, unless amended. Alternatively, a single Series may be 
created and contain multiple reports if different laboratory exams were requested in the 
same order. 
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4. Study Instance UIDs, Series Instance UIDs and SOP Instance UIDs may be created by 
the External Report Repository Access to group one or more of its Reports. Those 
UIDs need to be properly formed DICOM UIDs, i.e. use a registered root. 

5. If the same Report is being queried and retrieved several times, the same set of Study, 
Series and SOP Instance UIDs shall be provided by the External Report Repository 
Access. This ensures that two separate queries selecting the same report will identify 
the same instance and retrieve an identical copy. This is important to avoid multiple 
copies with the same content confusing the clinician. 

6. Table E.2-1 shows the minimal set of matching and return keys that shall be supported 
by the External Report Repository Access as an SCP at the different DICOM 
Hierarchical Levels. It is a reduced set from the radiology department keys (see 
sections 6.14.4.1.2). Additional SR Instance specific keys that shall be supported by 
the External Report Repository Access as an SCP are defined in section 6.26.4.1.2 and 
table 6.26-1. Minimum DICOM conformance is still required. Conventions for table 
E.2-1 may be found in section 2.2. 

Note: The use of N/A (Not Applicable) in the SCU columns is because the External Report 

Repository Access is only an SCP of the query request. 


Table E.2-1. Query Matching and Return Keys 


Attributes Name 

Tag 

Query Keys Matching 

Query Keys Return 

Notes 

SCU 

SCP 

SCU 

SCP 

Study Level 

Study Date 

(0008,0020) 

N/A 

R 

N/A 

R 


Study Time 

(0008,0030) 

N/A 

R 

N/A 

R 


Accession Number 

(0008,0050) 

N/A 

R 

N/A 

R 


Patient Name 

(0010,0010) 

N/A 

R 

N/A 

R 

IHE- 1 . IHE-2 

Patient ID 

(0010,0020) 

N/A 

R 

N/A 

R 


Study ID 

(0020,0010) 

N/A 

R 

N/A 

R 


Study Instance UID 

(0020.000D) 

N/A 

R 

N/A 

R 


Referring Physician’s 
Name 

(0008,0090) 

N/A 

R+ 

N/A 

R+ 

IHE- 1 , IHE-2 

Study Description 

(0008,1030) 

N/A 

O 

N/A 

O 


Procedure Code 
Sequence 

(0008,1032) 

N/A 

O 

N/A 

O 

IHE- 3 

Patient’s Birth Date 

(0010,0030) 

N/A 

O 

N/A 

R+ 


Patient’s Sex 

(0010,0040) 

N/A 

O 

N/A 

R+ 


Series Level 

Modality 

(0008.0060) 

N/A 

R 

N/A 

R 

IHE-5 

Series Number 

(0020.0011) 

N/A 

R 

N/A 

R 


Series Instance UID 

(0020.000E) 

N/A 

R 

N/A 

R 


Composite Object Instance Level 
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Instance Number 

(0020.0013) 

N/A 

R 

N/A 

R 


SOP Instance UID 

(0008.0018) 

N/A 

R 

N/A 

R 


SOP Class UID 

(0008,0016) 

N/A 

R+ 

N/A 

R+ 

IHE-4 


IHE-1: Case insensitive matching is allowed in the IHE Technical Framework: Year 2, 

for attributes of VR PN. A DICOM Change Proposal (CP 190) to allow case 
insensitivity on PN attributes is currently pending. 

IHE-2: SCUs are recommended to append wildcard at the end of each component of 

any structured name to facilitate matching (i.e., PN attributes). 

IHE-3: Universal Matching (selecting return keys) against an Attribute of VR SQ should 

be requested by the Query SCU using a Zero Length Sequence Attribute. Query SCPs 
shall accept such Universal Match Requests. In addition, Query SCPs are required by 
the DICOM Standard to support requests for a Universal Match for an SQ attribute 
encoded as a zero length item. 

IHE-4: A SOP Class UID is a non-ambiguous key to identify a specific type of image 

(Modality is not). 

IHE-5: The Modality Matching Key will always be set to “SR” 

E.3: External Report Content 

The requirements for coded entries and report structure for reports handled by the External 
Report Repository via the Query Report and Retrieve Report Transactions shall be similar to the 
Report Creator (see section 6.24.4.1.2.1): 

• The types of reports generated by the External Report Repository are defined in section 
5.3.2. The External Report Repository shall be able to generate reports based on the 
Simple Image Report (section 5. 3. 2. 2) with optional image references. If image 
references are supported by the External Report Repository then it shall also support the 
Key Image Report (section 5.3.2. 1). If the External Report Repository supports the 
Enhanced SR Information Object Definition then it shall also support the generation of 
Simple Image and Numeric Reports (section 5. 3. 2. 3). 

• A specialized set of Report Titles, Report Section Headings, Concept Name Codes, 
Observation Context Codes, Measurement Codes and Disposition or Conclusion Codes 
will be defined for each type of department repository accessed (e.g. laboratory codes for 
laboratory departments) 
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Appendix F: Overview of the Information Exchange between 

DSS/Order Filler and Image Manager 

Information exchange between the DSS/Order Filler and the Image Manager is performed on the 
intra-departmental level. Each actor manages a distinct domain of information within a 
department: patient, order and procedure performance information for the DSS/Order Filler; 
image acquisition, storage and interpretation for the Image Manager. Each system, however, 
requires valid and current information from both domains. 

F.1 : Exchange of Patient Information 

The DSS/Order Filler is a source of patient information for the Image Manager within the 
context of a department. The Image Manager does not receive information for a particular patient 
until the first order for a patient has been submitted to the department and corresponding 
procedures have been scheduled. At this point, the DSS/Order Filler will communicate patient 
information to the Image Manager within Transaction 4: Procedure Scheduled. 

Subsequent updates of patient information are communicated by the DSS/Order Filler to the 
Image Manager via Transaction 12: Patient Update. These changes will be reflected on the 
Image Manager and in the images and Grayscale Softcopy Presentation State objects retrieved 
from the Image Archive. No patient information changes should be initiated by the Image 
Manager. 

F.2: Exchange of Visit and Order Information 

The DSS/Order Filler is a source of visit and order information for the Image Manager. The 
Image Manager does not receive information for a particular patient’s visit until the first order 
for a patient originated within such a visit has been submitted to the department and 
corresponding procedures have been scheduled. At this point, the DSS/Order Filler will 
communicates visit and order information to the Image Manager within Transaction 4: Procedure 
Scheduled. 

Subsequent updates of visit information are communicated by the DSS/Order Filler to the Image 
Manager via Transaction 12: Patient Update. These changes will be reflected on the Image 
Manager and in the images and Grayscale Softcopy Presentation State objects retrieved from the 
Image Archive. No visit information changes should be initiated by the Image Manager. 

Because the IHE Technical Framework requires that the order information change will be 
performed through cancellation of the order in question and re-order, updates of order 
information are communicated by the DSS/Order Filler to the Image Manager via a sequence of 
two transactions - Transaction 13: Procedure Update (conveying order cancel) and Transaction 4: 
Procedure Scheduled (conveying new order information). No order information changes should 
be initiated by the Image Manager. 
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F.3: Exchange of Procedure Information 

The DS S/Order Filler is a source of Requested Procedure information for the Image Manager. 
The Image Manager does not receive information for a particular procedure until it has been 
scheduled. At this point, the DSS/Order Filler will communicate visit and order information to 
the Image Manager within Transaction 4: Procedure Scheduled. 

Subsequent updates of procedure information (re-scheduling, change of procedure code, etc.) are 
communicated by the DSS/Order Filler to the Image Manager via Transaction 13: Procedure 
Update. No Requested Procedure information changes should be initiated by the Image Manager. 

Certain imaging information, submitted to the Image Manager from the Acquisition Modality, 
shall not be subject of change by either the DSS/Order Filler or the Image Manager. This 
information includes Study Instance UID and the Performed Procedure, Performed Procedure 
Step and Performed Action Item information. 
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Appendix G: Clarification of Patient Identifiers for Merge Cases 

G.1: Introduction 

IHE Technical Framework: Year 2 has adopted the changes in HL7 2.3.1 Patient Identifiers. 

This includes: 

• HL7 v2.3 External Patient ID (PID -2) has been retained for backward compatibility. 

• Alternate Patient ID (PID-4) has been retained for backward compatibility. 

• Internal Patient ID (PID-3) has been renamed “Patient Identifier List” and is now allowed 
to repeat. 

Due to the adoption of these HL7 2.3.1 changes, IHE mandates the use of assigning authority 
(issuer) in PID-3 component 4 and identifier in PID-3 component 1. 

Since the DICOM Patient ID attribute (0010,0020) does not convey assigning authority and the 
Issuer of Patient ID (0010,0021) is an optional attribute in DICOM, both the Image Manager 
Actor and the Department System Scheduler/Order Filler Actor should be prepared to make 
assumptions regarding the assigning authority for Patient IDs transmitted from a Modality via 
DICOM Modality PPS. It is assumed that it is possible to recognize a valid range of patient 
identifiers assigned by a single ADT Actor or single issuer of identifiers within an enterprise. 

The identifier in PID-3 in all HL7 transactions specified by the IHE shall be single valued and 
used by the ADT/Patient Registration actor, except for Transaction 4 which may use an identifier 
assigned by the DSS/Order Filler. 

In future years of IHE with the introduction of an MPI, it is assumed that the MPI identifier will 
be used in PID-3 for all HL7 transactions. 

It is required that the healthcare institution configure the issuer of temporary patient identifiers to 
be either the ADT Issuer or the Departmental Issuer in both the Image Manager and the 
DSS/Order Filler. This will ensure that Patient ID in DICOM (0010,0020) is associated with the 
same assigning authority when mapped into a PID-3 in HL7 messages. 

Although, an organization may operate with temporary patient identifiers issued by the ADT and 
used primarily in Cases 1,2 and 3, Case 5 may occur. This may happen due to Modality operator 
errors when manually entering patient identifier in Case 3. In this situation, DSS/Order Filler 
and Image Manager shall recognize the error and associate the erroneous identifier to the same 
issuer. The reconciliation will happen on the DSS/Order Filler and it will send the Patient Merge 
message to the Image Manager where both “new” and “old” patient identifiers are associated 
with the same issuer. 

The use of PID-3 is illustrated in the following sections using the section 5 use cases. In the 
examples given below time flows from the top row of the table to the bottom. 
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Table 

Acronyms 

Description 

IM 

Image Manager 

OF 

Order Filler / Departmental System Scheduler 

OP 

Order Placer 

PPSM 

Performed Procedure Step Manager 


G.2: Administrative Process Flow (Section 5.1.1) 

The illustration includes A01, A04, A05, All, and A30 although only an A01 is included in this 
example. The ADT identifier number used in the example below is “123”, the assigning 
authority is “ADT_Issuer”. 


Transaction 

PID-3 

DICOM 

MRG-1 


(Patient Identifier List) 

(0010,0020) 

(Prior Patient Identifier List) 

A01 (ADT -> OF) 

123 A A A ADT_Is suer 

N/A 

N/A 

A01 (ADT -> OP) 

123 A A A ADT_Is suer 

N/A 

N/A 

ORM (OP->OF) 

1 2 3 A A A ADT_Is suer 

N/A 

N/A 

ORM (OF->IM) 

123 A A A ADT_Issuer 

N/A 

N/A 

DICOM MWL 
(OF -> Modality) 

N/A 

123 

N/A 

PPS (Modality -> PPSM) 

N/A 

123 

N/A 

PPS (PPSM -> IM) 

N/A 

123 

N/A 

PPS (PPSM -> OF) 

N/A 

123 

N/A 


G.3: Patient Merge (Section 5.1.2) 

This specifically looks at the Patient merge scenario in section 5. 1.2.2. The “old” ADT identifier 
number used in the example below is “123”, the assigning authority is “ADT_Issuer”. The 
“new” ADT identifier number used in the example below is “456”, the assigning authority is 
“ADT_Issuer”. 


Transaction 

PID-3 

DICOM 

MRG-1 


(Patient Identifier List) 

(0010,0020) 

(Prior Patient Identifier List) 

A01 (ADT -> OF) 

1 23 AAA ADT_Issuer 

N/A 

N/A 

A01 (ADT -> OP) 

1 23 AAA ADT_Issuer 

N/A 

N/A 

ORM (OP->OF) 

1 23 AAA ADT_Issuer 

N/A 

N/A 

ORM (OF->IM) 

1 23 AAA ADT_Issuer 

N/A 

N/A 

DICOM MWL 

N/A 

123 

N/A 

(OF -> Modality) 




A40 (ADT -> OF) 

456 AAA ADT_Issuer 

N/A 

123 A A A ADT_Is suer 

A40 (OF->IM) 

456 AAA ADT_Issuer 

N/A 

123 AAA ADT_Issuer 
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A40 (ADT -> OP) 

456 AAA ADT_Issuer 

N/A 

1 23 AAA ADT_Issuer 


G.4: Trauma Cases 1 and 2 (Section 5. 4) 

The ADT temporary identifier for “John Doe” used in the example below is “Temp_123”, the 
assigning authority is “ADT_Issuer”. 


Transaction 

PID-3 

DICOM 

MRG-1 


(Patient Identifier List) 

(0010,0020) 

(Prior Patient Identifier List) 

A01 (ADT -> OF) 

Temp_123 AAA ADT_Issuer 

N/A 

N/A 

A01 (ADT -> OP) 

Temp_123 AAA ADT_Issuer 

N/A 

N/A 

ORM (OP->OF) 

Temp_123 AAA ADT_Issuer 

N/A 

N/A 

ORM (OF->IM) 

Temp_123 AAA ADT_Issuer 

N/A 

N/A 

DICOM MWL 

N/A 

Temp_123 

N/A 

(OF -> Modality) 




PPS (Modality -> PPSM) 

N/A 

Temp_123 

N/A 

PPS (PPSM -> IM) 

N/A 

Temp_123 

N/A 

PPS (PPSM -> OF) 

N/A 

Temp_123 

N/A 

A40 (ADT -> OF) 

456 AAA ADT_Issuer 

N/A 

123 A A A ADT_Is suer 

A40 (OF->IM) 

456 AAA ADT_Issuer 

N/A 

123 AAA ADT_Issuer 

A40 (ADT -> OP) 

456 AAA ADT_Issuer 

N/A 

123 AAA ADT_Issuer 


G.5: Trauma Case 3 (Section 5. 4) 

The ADT temporary identifier number for “John Doe” used in the example below is 
“Temp_123”. The patient will later be assigned a permanent identifier of “Real_456”, the 
assigning authority is “ADT_Issuer”. 


Transaction 

PID-3 

DICOM 

MRG-1 


(Patient Identifier List) 

(0010,0020) 

(Prior Patient Identifier List) 

A01 (ADT -> OF) 

Temp_123 AAA ADT_Issuer 

N/A 

N/A 

A01 (ADT -> OP) 

Temp_123 AAA ADT_Issuer 

N/A 

N/A 

(Note: Temporary Patient ID 
“Temp_123” is manually 
entered at the modality.) 

N/A 

N/A 

N/A 

PPS (Modality -> PPSM) 

N/A 

Temp_123 

N/A 

PPS (PPSM -> IM) 

N/A 

Temp_123 

N/A 

(Note: The IM recognizes an 
unscheduled PPS and 
assumes a site configured 
assigning authority of 

N/A 

N/A 

N/A 
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“ADT_Issuer”.) 




PPS (PPSM -> OF) 

N/A 

Temp_123 

N/A 

(Note: The OF recognizes 
an unscheduled PPS with a 
valid ADT Patient ID - with 
a site configured assigning 
authority of "ADT_Issuer”.) 

N/A 

N/A 

N/A 

ORM (OF-> OP) 

Temp_ 1 23 AAA ADT_Issuer 

N/A 

N/A 

ORR (OP->OF) 

Temp_123 AAA ADT_Issuer 

N/A 

N/A 

ORM (OF-> IM) 

Temp_ 1 23 A AA ADT_Issuer 

N/A 

N/A 

(Note: Patient Reconciliation 
occurs on the ADT system.) 

N/A 

N/A 

N/A 

A40 (ADT -> OF) 

Real_456 AAA ADT_Issuer 

N/A 

Temp_123 AAA ADT_Issuer 

A40 (ADT -> OP) 

Real_456 AAA ADT_Issuer 

N/A 

Temp_123 AAA ADT_Issuer 

A40 (OF-> IM) 

Real_456 AAA ADT_Issuer 

N/A 

Temp_123 AAA ADT_Issuer 


G.6: Trauma Case 4 (Section 5.4) 

The OF temporary identifier number for “John Doe” used in the example below is “Dept_789”. 
The Patient will later be assigned a permanent identifier of “123”, the assigning authority is 
“OF_Issuer”. 


Transaction 

PID-3 

DICOM 

MRG-1 


(Patient Identifier List) 

(0010,0020) 

(Prior Patient Identifier List) 

ORM (OF->IM) 

Dept_789 AAA OF_Issuer 

N/A 

N/A 

DICOM MWL 
(OF->Modality) 

N/A 

Dept_789 

N/A 

PPS (Modality -> PPSM) 

N/A 

Dept_789 

N/A 

PPS (PPSM -> IM) 

N/A 

Dept_789 

N/A 

(Note: The IM recognizes a 
scheduled PPS with a Patient 
ID - with a site configured 
assigning authority of 
“OF_Issuer”.) 

N/A 

N/A 

N/A 

PPS (PPSM -> OF) 

N/A 

Dept_789 

N/A 

(Note: The OF recognizes a 
scheduled PPS with a Patient 
ID issued by the OF.) 

N/A 

N/A 

N/A 

A01 (ADT -> OP) 

123 A A A ADT_Is suer 

N/A 

N/A 

A01 (ADT -> OF) 

123 A A A ADT_Is suer 

N/A 

N/A 

(Note: The patient 
Dept_789 AAA OF_Issuer is 
manually reconciled with 
123 A A A ADT_Is suer. ) 

N/A 

N/A 

N/A 

A40 (OF-> IM) 

123 AAA ADT Issuer 

N/A 

Dept_7 89 A A A OF_Is suer 

ORM (OF-> IM) 

123 A A A ADT_Issuer 

N/A 

N/A 
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ORM (OF-> OP) 

123 AAA ADT_Iss Uer 

N/A 

N/A 

ORR (OP->OF) 

1 2 3 A A A ADT_Is suer 

N/A 

N/A 


G.7: Trauma Case 5 (Section 5. 4) 

The temporary identifier number for “John Doe” used in the example below is “Dept_123” and 
is manually entered on the Modality. The patient will later be assigned a permanent identifier of 
“Real_456”, the assigning authority is “OF_Issuer”. 


Transaction 

PID-3 

(Patient Identifier List) 

DICOM 

(0010,0020) 

MRG-1 

(Prior Patient Identifier List) 

PPS (Modality ->IM) 

N/A 

Dept_123 

N/A 

(Note: The IM 
recognizes an 
unscheduled PPS and 
assumes a site 
configured assigning 
authority) 

N/A 

N/A 

N/A 

PPS (IM->OF) 

N/A 

Dept_123 

N/A 

(Note: The OF 
recognizes an 
unscheduled PPS and 
assumes a site 
configured assigning 
authority; recognizes 
that Patient ID is 
invalid.) 

N/A 

N/A 

N/A 

A01 (ADT->OF) 

Real_456 AAA ADT_Issuer 

N/A 

N/A 

A01 (ADT->OP) 

Real_456 AAA ADT_Issuer 

N/A 

N/A 

(Note: Manual patient 
reconciliation occurs on 
the OF system.) 

N/A 

N/A 

N/A 

A40 (OF-> IM) 

Real_456 AAA ADT_Issuer 

N/A 

Dept_123 AAA Configured_Issuer 

ORM (OF-> OP) 

Real_456 AAA ADT_Issuer 

N/A 

N/A 

ORR (OP->OF) 

Real_456 AAA ADT_Issuer 

N/A 

N/A 

ORM (OF-> IM) 

Real_456 AAA ADT_Issuer 

N/A 

N/A 
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GLOSSARY 


Terms Specific to this Document 

Accession Number: A user-friendly identifier created by the Departmental System, which 
identifies an instance of a filler order or imaging service request. It may group one or 
more requested procedures. 

Actor: An entity within a use case diagram which can perform an action within a use case 

diagram. Possible actions are creation or consumption of a message 

Expected Actions: Actions which should occur as the result of a trigger event 

Foreign Key (FK): A database key which is used as a reference to relate one entity to another 
entity. It may be a unique value, or used in conjunction with another Foreign Key to 
create a unique value. 

Images Available: A transaction or transactions used to determine that images have been stored 
in an image archive and may be retrieved. 

Interaction Diagram: A diagram which depicts data flow and sequencing of events 

Pre-fetch: The activity of fetching images or other information objects from previously 
completed procedures to near-term storage for review of those data. 

Process Flow Diagram: A graphical illustration of the flow of processes and interactions among 

the actors involved in a particular example 

Role: The actions of an actor in a use case. 

Scope: A brief description of the process step. 

Trigger Event: An event such as the reception of a message or completion of a process, which 
causes another action to occur. 

Use Case: A graphical depiction of the actors and operation of a system. 


DICOM Terms 

Action Item: See DICOM PS 3.3 

Basic Color Print Management Meta SOP Class: See DICOM PS 3.4 

Basic Grayscale Print Management Meta SOP Class: See DICOM PS 3.4 

Basic Text SR Storage SOP Class: See DICOM Supplement 23 

DICOM Model of the Real World: See DICOM PS 3.3 

Enhanced SR Storage SOP Class: See DICOM Supplement 23 

Grayscale Softcopy Presentation State Storage SOP Class: See DICOM PS 3.4 

Grayscale Standard Display Function: DICOM PS 3.14 

Imaging Service Request: See DICOM PS 3.3 

Modality: See DICOM PS 3.3 


194 


Rev. 4.0 Copyright © 2000: HIMSS/RSNA 

03-28-2000 



IHE Technical Framework: Year 2 


Modality Worklist SOP Class: See DICOM PS 3.4 

Modality Performed Procedure Step: See DICOM PS 3.3 

Modality Performed Procedure Step Information Module: See DICOM PS 3.3 

Modality Performed Procedure Step Relationship Module: See DICOM PS 3.3 

Modality Performed Procedure Step SOP Class: See DICOM PS 3.4 

Patient: See DICOM PS 3.3 

Patient Identification Module: See DICOM PS 3.3 

Print Presentation LUT SOP Class: See DICOM PS 3.4 

Procedure Plan: See DICOM PS 3.3 

Procedure Type: See DICOM PS 3.3 

Requested Procedure: See DICOM PS 3.3 

Requested Procedure Module: See DICOM PS 3.3 

Requested Procedure ID: See DICOM PS 3.3 

Results Information Object Definition: See DICOM PS 3.3 

Scheduled Procedure Step: See DICOM PS 3.3 

Scheduled Procedure Step Module: See DICOM PS 3.3 

Storage Commitment SOP Class: See DICOM PS 3.4 

Stored Print SOP Class: See DICOM PS 3.4 

Structured Reporting SOP Classes: See DICOM Supplement 23 

Unique Identifier (UID): See DICOM PS 3.5 


HL7 Terms 

ADT: See HL7 version 2.3.1 

Battery: See HL7 version 2.3.1 

Filler: See HL7 version 2.3.1 

Observation: See HL7 version 2.3.1 

Placer: See HL7 version 2.3.1 

Universal Service ID: See HL7 version 2.3.1 


Acronyms and Initialisms 

GSPS: Grayscale Softcopy Presentation State 

HIMSS: Healthcare Information and Management Systems Society 

HIS: Hospital Information System 

IHE: Integrating the Healthcare Enterprise 

IOD: Information Object Definitions 
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LUT: Look Up Table 

MPI: Master Patient Index 

MWL: Modality Worklist 

MPPS: Modality Performed Procedure Step 

NEMA: National Electrical Manufacturers Association 

PACS: Picture Archive and Communication System 

PPS: Performed Procedure Step 

RIS: Radiology Information System 

RSNA: Radiological Society of North America 

SCU: Service Class User 

SCP: Service Class Provider 

SR: Structured Report 

UID: Unique Identifier 
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